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About  This  Roadmap 


Organization  of 
the  Roadmap 


The  Software  Process  Improvement  Roadmap  is  the  product  of  a 
strategic  collaboration  between  the  Carnegie  Mellon  University 
Software  Engineering  Institute  (SEI)  and  the  Hewlett-Packard  Com¬ 
pany.  The  information  in  the  roadmap  is  based  on  the  application  of 
software  process  improvement  practices  and  the  lessons  learned 
from  these  experiences.  Concepts  in  the  roadmap  were  proven  with 
the  SEI  client  base  within  the  Department  of  Defense  and  the  inter¬ 
nal  Hewlett-Packard  clients. 

The  roadmap  is  also  based  on  the  work  of  several  projects  at  the  SEI. 
SEI  projects  whose  work  contributed  directly  or  indirectly  to  the  ma¬ 
terial  in  this  roadmap  are:  Capability  Maturity  Model,  Software  Pro¬ 
cess  Assessment,  Software  Capability  Evaluation,  Organization  Ca¬ 
pability  Development,  Software  Process  Measurement,  and  Soft¬ 
ware  Process  Definition. 

We  describe  six  major  activities  of  software  process  improvement  in 
Chapters  1.0  through  6.0.  In  general,  we  limit  the  chapter  structure 
to  three  levels  of  detail.  We  provide  additional  detail  in  the 
appendices: 

•  Appendix  A.0:  Taxonomy  of  Software  Process  Improvement 
Plans  and  Charters  (page  145). 

•  Appendix  B.0:  Components  of  the  Software  Process  Improve¬ 
ment  Infrastructure  (page  159). 

Appendix  C.0:  Charters  and  Templates  (page  175). 

•  Appendix  D.0:  Establish  Organization  Process  Maturity  Base¬ 
line  (page  193). 

Following  these  appendices,  we  provide  a  glossary  (page  205). 
When  we  introduce  a  new  term  or  key  phrase  in  the  text  for  the  first 
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time,  we  print  the  term  or  phrase  in  bold  typeface  to  indicate  that  it 
is  defined  in  the  glossary.  There  is  also  an  index  on  page  209. 
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Introduction 


Introduction 


Overview  This  document  describes  a  generic  software  process  improvement 

(SPI)  program  roadmap,  a  long-range,  integrated  plan  for  initiating 
and  managing  a  SPI  program.  The  purpose  of  this  document  is  to 
provide  process  improvement  managers  with  a  generic  description 
of  the  recommended  steps  for  SPI. 


Figure  1-1  on  page  2  shows  a  high-level  view  of  the  roadmap.  The 
roadmap  is  intended  to  address  two  operational  levels: 

•  A  strategic  level,  in  which  there  are  processes  that  are  the  re¬ 
sponsibility  of  senior  management. 

•  A  tactical  level,  in  which  processes  are  executed  by  line  manag¬ 
ers  and  practitioners. 
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Introduction 


Figure  1-1:  High-level  View  of  Process  Improvement  Roadmap 


The  flow  depicted  in  Figure  1-1  is  a  continuous  flow.  As  improve¬ 
ment  activity  is  completed,  both  the  strategic-level  and  tactical-level 
activities  return  to  1.0,  Initiate  Software  Process  Improvement, 
where  management  commitment  is  reaffirmed,  new  baselines  are 
planned,  or  strategy  is  redirected. 

The  roadmap  describes  a  process  improvement  program  that  occurs 
in  three  phases,  made  up  of  six  major  activities  within  these  phases. 
The  three  phases  are 
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1 .  Initiating  process  improvement;  analogous  to  the  “Initiate” 
phase  of  the  Software  Engineering  Institute  (SEI)  IDEAL  mod¬ 
el. 

2.  Baselining  or  understanding  the  current  processes  and  opportu¬ 
nities;  analogous  to  the  “Diagnosing”  and  “Establishing”  phases 
of  the  IDEAL  model. 

3.  Implementing  process  improvement  by  developing  and  sustain¬ 
ing  improvements  within  the  organization;  analogous  to  the 
“Acting”  and  “Leveraging”  phases  of  the  IDEAL  model. 

Structure  of  the  As  shown  in  Figure  1-1  on  page  2,  the  roadmap  consists  of  six  main 
Roadmap  activities.  These  activities  describe  a  set  of  processes  that  are  exe¬ 

cuted  during  the  implementation  of  a  SPI  program.  Descriptions  of 
these  activities  comprise  the  remaining  six  chapters  of  this  roadmap. 
The  major  activities  in  Figure  1-1  match  the  chapters  within  the  doc¬ 
ument  and  are  made  up  of  a  number  of  subactivities. 

The  activities  in  the  roadmap  are  listed  and  briefly  summarized  in 
the  following  table: 


Process  Name 

Process  Purpose 

See 

Page 

1.0:  Initiate  Software  Process  Improvement 

Learn  about  process  improvement, 
commit  initial  resources,  and  build 
process  infrastructure. 

7 

2.0:  Manage  the  Software  Process 
Improvement  Program 

Track  improvement  projects  and  resolve 
issues. 

43 

3.0:  Build  Software  Process  Improvement 
Strategy 

Develop  strategic  and  tactical  plans  for 
specific  improvements. 

69 

4.0:  Baseline  Current  State 

Establish  current  levels  of  process 
maturity,  process  descriptions,  metrics, 
etc. 

99 

5.0:  Develop  Improvements 

Research  and  develop  solutions  to 
process  problems. 

103 

6.0:  Deploy  Improvements 

Expand  successful  process 
improvements  to  entire  organization. 

125 

In  general,  the  chapter  structure  has  been  limited  to  three  levels  of 
detail.  Additional  detail  is  provided  in  the  appendices. 
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Purpose 


Some  Assembly 
Required:  One 
Size  Does  Not  Fit 
All! 


The  roadmap  is  intended  to  be  general  and  does  not  presuppose  or 
force  any  particular  methodology.  For  a  list  of  sources  that  can  be 
used  to  support  and  help  ensure  a  successful  SPI  program,  see  the 
SEI  Annotated  Listing  of  Documents  } 

The  roadmap  is  intended  to  provide  an  organization  with  a  guide  to 
forming  and  carrying  out  a  SPI  program.  It  is  written  primarily  from 
the  point  of  view  of  the  organization  setting  up  the  program,  not 
from  an  external  consultant’s  or  solution  provider’s  point  of  view. 
The  expected  users  are  the  champions  of  SPI,  mainly  SPI  program 
managers.  Other  users  include  senior  managers,  line  managers,  and 
individuals  who  are  interested  and/or  have  a  stake  in  improving  the 
software  development  capability  of  the  organization. 

The  roadmap  is  organized  in  a  best-case  sequence.  However,  there 
will  always  be  real-world  events  that  prevent  organizations  from  fol¬ 
lowing  a  set  sequence  in  process  improvement.  SPI  managers  must 
tailor  the  roadmap  to  their  particular  situation  of  process  improve¬ 
ment.  The  sequence  presented  here  is  recommended  because  as 
baselines  are  completed,  the  SPI  managers  and  practitioners  will 
come  under  increasing  pressure  to  produce  plans  and  actions.  Be¬ 
cause  it  will  be  difficult  to  allocate  time  for  organizing  and  planning 
later  in  the  process,  managers  must  make  sure  that  time  is  allocated 
up  front.  Clear  understanding  of  what  will  be  done  and  when  it  will 
be  done  will  be  invaluable  for  maintaining  the  momentum  of  a  SPI 
program. 
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Organization  vs. 

Corporate 

Considerations 


The  roadmap  recommends  that  1-3%  of  an  organization’s  personnel 
be  applied  to  managing  and  executing  SPI.  Given  these  recommen¬ 
dations,  the  roadmap  is  intended  to  be  used  by  organizations  that  are 
large  enough  to  assign  at  least  one  full-time  and  one  part-time  person 
to  SPI.  At  least  two  people  are  needed  to  provide  synergy  and  back¬ 
up  in  activities.  Thus  organizations  with  fewer  than  50  people  will 
have  difficulty  sustaining  SPI  if  they  do  not  commit  to  the  minimum 
recommended  personnel  assignments.  Furthennore,  such  organiza¬ 
tions  may  not  be  complex  enough  to  require  the  additional  infra¬ 
structure  for  SPI. 

On  the  other  hand,  process  groups  in  large  organizations  can  become 
too  bureaucratic  and  may  lose  contact  with  the  technical  staffs  they 
are  designed  to  help.  Large  organizations  (more  than  600  people) 
should  divide  process  groups  into  the  corporate  organizational  mod¬ 
el  described  in  this  document  (see  page  53). 

The  roadmap  is  primarily  focused  on  organization-specific  activi¬ 
ties.  To  be  successful,  such  activities  do  not  require  a  corporate  pro¬ 
gram.  A  corporate  program  cannot  fulfill  all  (or  many)  of  the  func¬ 
tions  of  an  organization  program: 

•  It  is  too  far  away. 

•  There  is  too  much  “normalization.”  That  is,  the  organization 
subcultures  are  too  different  for  a  single  set  of  practices  and  so¬ 
lutions. 

There  are  never  enough  resources  (resources  would  be  spread 
too  thin). 

However,  the  roadmap  does  include  those  activities  for  which  a  cor¬ 
porate  office  would  be  responsible.  Within  a  corporation  that  is 
made  up  of  a  number  of  separate  organizations,  there  may  and  prob¬ 
ably  will  exist  a  hierarchy  of  SPI  programs.  The  corporate  program 
would  perform  activities  in  its  corporate  context,  including 

•  Establishing  infrastructure  and  links  to  support  and  coordinate 
the  organization  programs. 

Looking  outside  the  corporation  for  “process  reuse.” 

•  Supporting  organizational  roadmap  activities  through  resources, 
common  practices,  communication,  etc. 
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Spreading  findings,  practices,  infonnation,  etc.,  across  a  wider 
base  within  the  corporation. 

Acting  as  a  focal  point  for  outside  process  improvement 
influences,  such  as  those  from  the  SEI,  ISO  9000,  etc. 
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Initiate  Software  Process  Improvement 


i.o  Initiate  Software  Process 

Improvement 


Overview  This  is  the  initial  step  in  the  roadmap,  where  the  organization’s  se¬ 

nior  management  first  understands  and  commits  to  a  software  pro¬ 
cess  improvement  (SPI)  program  and  then  defines  the  context  for 
SPI.  Although  process  improvement  is  cyclical,  this  context-setting 
step  occurs  only  once,  when  the  SPI  program  begins. 


This  step  is  similar  to  the  definition  of  a  new  system.  A  plan  and 
schedule  are  developed,  major  functional  elements  defined,  and  key 
interfaces  and  requirements  defined  and  agreed  to.  Typically  a  dis¬ 
covery  team  is  formed  to  explore  the  issues  and  to  develop  a  SPI 
proposal  to  senior  management.  Following  the  approval  of  the  SPI 
proposal,  the  infrastructure  for  launching  the  SPI  program  will  be 
formed. 

Each  organization  should  decide  how  it  will  organize  its  improve¬ 
ment  efforts;  who  will  be  involved,  both  at  the  practitioner  and  man¬ 
agement  levels;  and  how  much  of  those  people’s  time  will  be  allo¬ 
cated  to  the  effort.  Based  on  these  initial  decisions,  the  charter  and 
staffing  for  the  management  steering  group  (MSG),  soft¬ 
ware  engineering  process  group  (SEPG),  and  other  organiza¬ 
tional  entities  are  assigned.  These  entities  then  develop  working  pro¬ 
cedures,  plans,  and  schedules  to  steer  the  organization  through  the 
process  improvement  program.  Appendix  B.0,  Components  of  the 
Software  Process  Improvement  Infrastructure  (page  159),  further 
defines  the  organizational  structures. 

Planning  is  very  important  in  this  step.  Once  baselining  efforts  are 
under  way,  the  MSG  and  SEPG  will  come  under  increasing  pressure 
to  produce.  It  is  usually  very  difficult  to  allocate  enough  time  at  that 
point  to  organizing  the  effort.  A  clear  understanding  by  both  the 
MSG  and  the  SEPG  of  what  will  be  done,  how,  and  when,  before  the 
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baselining  activities,  is  essential  for  setting  the  stage  for  effective 

work  afterwards. 

Purpose  The  purpose  of  this  step  is  to 

•  Launch  the  SPI  program  by  building  an  understanding  and  an 
awareness  of  the  costs  and  benefits. 

•  Determine  the  business  needs  for  process  improvement. 

•  Commit  the  resources  necessary. 

•  Form  the  initial  infrastructure  needed  to  implement  and  manage 
the  program. 

During  this  process  there  will  be  three  main  outputs: 

1 .  A  SPI  proposal  to  senior  management. 

2.  An  infrastructure  to  initiate  and  manage  the  program. 

3.  A  SPI  implementation  plan  for  all  activities  through  the  baselin¬ 
ing  step. 

Objectives  The  objectives  for  this  step  are  listed  by  team  in  the  table  below: 


Team 

Objective 

Discovery  Team 

Build  initial  awareness,  skills,  and  knowledge  to  start  SPI. 

Determine  business  objectives  related  to  SPI. 

Determine  readiness  to  proceed. 

Create  a  proposal  for  a  SPI  program,  outlining  the  needs  for  SPI,  the  scope  of  the 
program,  and  resource  requirements.  Also,  recommend  an  overall  schedule  and 
infrastructure  to  manage  the  program. 

Senior 

Management 

Commit  the  resources  to  accomplish  the  next  steps. 

Create  organizational  components  for  a  SPI  program. 

Commit  in  principle  to  the  overall  process. 

MSG  and  SEPG 

Plan  for  the  next  step  and  commit  to  the  next  steps. 

Table  1-1:  Objectives 
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Education/Training  Because  the  organization  is  just  starting  to  learn  about  SPI  and  how 

to  go  about  launching  a  SPI  program,  this  step  requires  substantial 
education  and  training.  The  table  below  shows  the  breakdown  of  ed¬ 
ucation  and  training  needs: 


Team 

Software 

Process 

Maturity 

Overview 

Software 

Process 

Improvement 

Overview 

Software 
Process  Improve¬ 
ment  Roadmap 
Overview 

Managing  Tech¬ 
nological  Change 

Planning  a 
SPI 

Program 

Discovery  Team 

X 

X 

X 

Key 

Organization 

Stakeholders 

X 

X 

X 

Senior 

Management 

X 

X 

X 

MSG 

X 

X 

X 

X 

X 

SEPG 

X 

X 

X 

X 

X 

Table  1-2:  Education  and  Training  Needs 


Commitment  Commitment  is  key  to  this  step.  Without  strong,  infonned,  and 

steadfast  commitment  and  sponsorship  from  senior  management, 
the  effort  is  doomed  from  the  start.  If  the  champion  cannot  obtain  the 
level  of  commitment  described  in  this  roadmap,  the  effort  is  better 
deferred  until  the  commitment  is  present. 

Senior  management’s  initial  commitment  is  to 

•  Allow  the  discovery  team  to  form  and  to  explore  the  issues  and 
develop  a  SPI  proposal. 

•  Provide  the  discovery  team  with  the  business  need  for  process 
improvement. 

This  is  followed  by  committing  to  implement  the  SPI  proposal  and 
backed  up  by  assigning  resources  to  the  SEPG  and  creating  other 
necessary  SPI  infrastructure  elements. 

The  line  management  stakeholders  also  must 
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Communication 


Entry  Criteria 


•  Commit  time  and  effort  to  participate  in  SPI. 

•  Form  and  commit  time  to  the  MSG. 

•  Plan  to  manage  the  SPI  program  and  develop  a  strategy  in  the 
steps  that  follow. 

Prospective  SEPG  members  also  must  commit  time  to  work  on  the 
SEPG  and  understand  that  this  commitment  could  result  in  a  sub¬ 
stantial  change  in  their  work  assignments  within  the  organization. 

The  discovery  team  will  regularly  communicate  the  results  of  its 
work  to  the  whole  organization  and  to  key  organization  stakeholders 
and  senior  management  in  particular.  These  communications  take 
the  fonn  of  general  information  exchanges  about  what  the  team  is 
learning  and  what  is  happening,  along  with  specific  requests  for  de¬ 
cisions  and  commitment  from  senior  management. 

Senior  management  must  communicate  the  business  objectives,  ra¬ 
tionale  for  the  SPI  program,  and  the  urgency  of  those  efforts.  They 
must  show  to  the  organization  active  commitment  to  the  effort. 

Once  the  infrastructure  is  fonned,  the  MSG  and  SEPG  must  main¬ 
tain  a  steady  flow  of  information  throughout  the  organization  about 
what  is  happening.  In  the  absence  of  any  specific  infonnation,  peo¬ 
ple  tend  to  assume  the  worst.  A  change  effort  of  this  magnitude  caus¬ 
es  substantial  fear  throughout  the  organization;  resistance  to  change 
will  show  up  for  a  variety  of  reasons.  Regular  and  effective  commu¬ 
nications  can  alleviate  some  of  that  concern. 

Organizations  may  initiate  a  SPI  program  because  of  some  disaster 
or  impending  disaster  in  their  business  that  includes  their  software 
capabilities,  or  through  a  desire  to  maintain  or  improve  a  competi¬ 
tive  edge  through  the  quality  and  productivity  of  their  software  pro¬ 
cesses.  Usually  there  are  one  or  more  champions  of  SPI  who  lobby 
to  get  an  effort  started  and  investigate  ways  to  launch  a  program.  The 
key  entry  criteria  are 

Critical  business  need  to  improve  software  quality  and  produc¬ 
tivity. 
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Initiate  Software  Process  Improvement 


Exit  Criteria 


•  Organization  champion(s)  for  SPI. 

•  The  SPI  infrastructure  has  been  established  and  is  reinforcing 
sponsorship  and  promoting  SPI  concepts  and  activities. 

•  An  initial,  organization-specific  SPI  implementation  plan  has 
been  created  for  organizing  and  launching  the  SPI  program. 
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Initiate  Software  Process  Improvement 


Tasks 


The  figure  below  is  a  pictorial  representation  of  tasks  for  Step  1.0, 
Initiate  Software  Process  Improvement. 


Figure  1-1:  Process  Flow  for  Initiating  Step  1.0 
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1.0 


Initiate  Software  Process  Improvement 


The  subtasks  for  Step  1 .0,  Initiate  Software  Process  Improvement, 
are 


Subtask 

Page 

Number 

1.1:  Get  Started 

14 

1.2:  Identify  Business  Needs  and  Drivers  for  Improvement 

16 

1 .3:  Build  a  Proposal 

18 

1.4:  Educate  and  Build  Support 

21 

1.5:  Obtain  Approval  for  Proposal  and  Initial  Resources 

23 

1.6:  Establish  the  Software  Process  Improvement  Infrastructure 

25 

1 .7:  Assess  the  Climate  for  SPI 

40 

1.8:  Launch  the  Program 

42 
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1.1 


Initiate  Software  Process  Improvement 
Get  Started 


Purpose  The  purpose  of  this  activity  is  to  organize  a  discovery  team  to  put  to¬ 

gether  a  proposal  to  management  for  launching  a  SPI  program.  This 
team  will  gather  information  about 


Objectives 


Entry  Criteria 


Exit  Criteria 


Outputs 


Current  business  needs,  organizational  policies,  and  regulations 
that  may  affect  a  SPI  program. 

•  Other  change  programs  in  the  organization  that  are  under  way  or 
planned. 

•  Ways  to  run  a  SPI  program. 

The  team  will  then  select  a  specific  approach. 

•  Identify  organizations  that  are  stakeholders  in  a  SPI  program. 

•  Evaluate  and  select  an  approach  to  conducting  the  SPI  program. 

•  Critical  business  issues  driving  process  improvement. 

A  desire  to  improve  software  quality  and  productivity. 

•  Organization  champion(s)  for  SPI.  The  champions  may  come 
from  anywhere  in  the  organization,  including  practitioners  and 
middle  or  senior  management.  There  may  be  several  champions 
within  the  organization  or  only  one. 

•  The  SPI  discovery  team  exists. 

•  Existing  initiatives,  policies,  and  regulations  that  will  affect  the 
creation  of  a  SPI  program  have  been  identified. 

•  An  approach  to  launching  and  conducting  a  SPI  program  has 
been  selected  and  support  agreements  have  been  established. 
The  roadmap  is  such  an  approach,  but  it  requires  tailoring  and 
customizing  to  the  local  environment. 

•  List  of  initiatives,  policies,  and  regulations  and  a  preliminary 
analysis  of  their  effect,  either  as  barriers  or  leverage  points. 
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Initiate  Software  Process  Improvement 
Get  Started 


SPI  support  (consulting)  agreement. 

•  Form  a  discovery  team. 

Select  a  SPI  champion  with  the  necessary  leadership 
skills  to  lead  the  team  and  do  early  planning  and 
sponsorship  building. 

Select  representatives  of  stakeholder  groups  to  be 
involved  in  the  development  of  the  SPI  plans. 

•  Identify  the  SPI  climate  for  change. 

Identify  current  policies,  regulations,  and  initiatives  that  will 
support  or  impede  the  launching  of  a  SPI  program.  For  example, 
a  company  may  have  a  policy  regarding  annual  management 
training;  may  be  subject  to  government  agency  regulations,  such 
as  the  Food  and  Drug  Administration;  or  may  have  an  initiative 
to  achieve  ISO  9001  certification.  These  all  may  affect  a  SPI 
program. 

•  Get  infonnation  on  how  to  do  SPI. 

Identify  different  approaches  and  support  groups. 

Select  an  approach  that  fits  the  needs  and  environment  of 
the  organization  best. 

Establish  consulting  and  training  support  for  the 
approach  selected. 
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1.2  Identify  Business  Needs  and  Drivers  for 

Improvement 


Purpose  The  purpose  of  this  step  is  to  understand,  from  a  management  per¬ 

spective,  the  key  business  needs  driving  the  need  for  a  SPI  program. 

SPI  champions  usually  have  many  good  reasons  why  an  organiza¬ 
tion  should  launch  a  SPI  program,  but  their  reasons  are  rarely 
couched  in  business  terms  or  aligned  with  the  organization’s  busi¬ 
ness  needs.  This  activity  will  establish  the  need  for  a  SPI  program  in 
management  business  terms,  aligned  with  current  business  needs. 

Objectives  •  Identify  key  business  needs  that  drive  a  need  for  SPI. 

•  Link  SPI  program  to  business  needs. 

Entry  Criteria  •  The  SPI  discovery  team  exists. 

•  Senior  management  has  articulated  the  organization’s  business 
strategy. 

Exit  Criteria  The  key  business  needs  have  been  defined  and  links  established  as 

drivers  to  a  SPI  program. 

Outputs  •  Business  needs  and  drivers  for  proposal  and  SPI  strategic  action 

plan. 

•  Description  of  the  desired  state  of  process  improvement  for  the 
organization. 

Tasks  •  Collect  business  needs. 

Review  current  vision  statements  and  SPI  business 
focus. 

Collect  any  current  needs  identification  documents. 
Interview  key  management  stakeholders. 

•  Review  needs  to  detennine  those  that  can  be  fully  or  partially 
satisfied  through  a  SPI  program. 
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•  Define  how  the  SPI  program  can  satisfy  the  needs. 
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.3  Build  a  Proposal 


1.3  Build  a  Proposal 


Purpose  The  purpose  of  this  step  is  to  build  a  proposal  for  senior  management 

that  will  explain  what  the  SPI  program  is,  why  it  should  be  initiated, 
what  it  will  cost,  how  long  it  will  take  to  see  results,  and  what  ap¬ 
proach  is  selected.  The  proposal  should  answer  the  questions:  “What 
do  we  want  to  do?”  and  “Why  do  we  want  to  do  it?” 

This  will  lead  to  the  next  management  decision  point,  at  which  man¬ 
agement  decides  whether  or  not  to  go  ahead  with  the  SPI  program 
(see  Step  1.5,  Obtain  Approval  for  Proposal  and  Initial  Resources  on 
page  23). 

Objectives  Develop  and  deliver  a  SPI  proposal. 

Entry  Criteria  •  The  SPI  discovery  team  is  formed  and  in  place. 

•  Existing  initiatives,  policies,  and  regulations  that  will  affect  the 
creation  of  a  SPI  program  have  been  identified. 

•  An  approach  to  launching  and  conducting  a  SPI  program  has 
been  selected  and  SPI  consulting  support  agreements  estab¬ 
lished. 

Business  needs  and  drivers  for  the  proposal  are  defined. 

Exit  Criteria  The  proposal  is  completed  and  ready  to  be  delivered. 

Outputs  •  Completed  proposal. 

•  Organization  communication  plan. 

Tasks  •  Identify  key  management  stakeholders  to 

Get  inputs  for  the  proposal. 

Send  draft  proposal  to  them  for  review  and  comment. 
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1.3  Build  a  Proposal 


•  Come  to  consensus  with  senior  management  on  the  problem(s) 
addressed  by  the  SPI  program  proposal. 

•  Establish  goals  and  objectives  for  the  improvement  program,  en¬ 
suring  consistency  with  business  objectives  and  critical  business 
needs  previously  identified. 

•  Develop  a  vision  of  the  desired  state  of  the  organization’s  pro¬ 
cess  maturity. 

•  Determine  scope. 

Which  organizations  (R&D,  marketing,  manufacturing, 
quality,  etc.)  will  be  included. 

What  kinds  of  software  (product,  embedded,  mission, 
support,  etc.)  will  be  included. 

•  Determine  organizational  structure  for  managing  and  coordinat¬ 
ing  the  SPI  program,  including  roles  and  responsibilities  of 

Senior  management. 

Organization  support  groups. 

Corporate  support  groups. 

SEPG  (determine  membership  based  on  scope  of 
improvement  program). 

MSG  (determine  membership  based  on  scope  of 
improvement  program,  funding  sources,  and 
management  control  requirements). 

Other  entities. 

•  Develop  high-level  plan. 

Initial  high-level  activities  and  schedule  through  SPI 
program  launch. 

Determine  basic  resource  requirements  (people,  travel 
funds,  equipment,  consultants),  primarily  for  the  SEPG, 
key  managers,  and  staff  in  line  organization  and 
expected  baselining  teams. 

•  Determine  benefits  to  the  organization,  such  as  business  value 
(include  return  on  investment  if  appropriate),  improved  capabil¬ 
ities,  morale. 

•  Write  the  proposal  to  senior  management. 
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1.0  Initiate  Software  Process  Improvement 

1.3  Build  a  Proposal 


•  Conduct  reviews  to  refine  draft  proposal  with  key  stakeholders. 
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1.4  Educate  and  Build  Support 


Purpose  The  purpose  of  this  activity  is  to  create  awareness,  set  expectations, 

and  build  support  for  the  SPI  program  across  as  much  of  the  organi¬ 
zation  that  will  be  affected  by  the  SPI  program  as  possible.  This  ac¬ 
tivity  starts  early  and  continues  throughout  the  entire  program,  ad¬ 
justing  the  type  and  level  of  infonnation  presented  to  match  the  cur¬ 
rent  step  and  level  of  activities. 

The  intent  is  to  answer  the  question  “What  is  going  on  and  why  are 
we  doing  this?”  Support  is  built  by  involving  the  people  affected  by 
the  program  in  the  early,  defining  parts  of  the  program  when  they 
can  more  easily  make  a  difference  and  increase  their  stake  in  the  out¬ 
comes. 

Objectives  •  Communicate  the  business  need  for  SPI  to  the  organization. 

•  Involve  key  stakeholders  in  communicating  and  forming  the  SPI 
program. 

Entry  Criteria  •  The  SPI  discovery  team  is  formed  and  in  place. 

•  Existing  initiatives,  policies,  and  regulations  that  will  affect  the 
creation  of  a  SPI  program  have  been  identified. 

•  An  approach  to  launching  and  conducting  a  SPI  program  has 
been  selected  and  SPI  program  support  agreements  established. 

Exit  Criteria  Messages  that  must  be  communicated  at  this  point  in  the  program 

have  effectively  reached  their  audiences. 

There  is  no  real  exit  from  this  activity,  as  the  need  to  educate  and 
build  support  for  process  improvement  continues  throughout  the 
program. 

Outputs  •  Organization  communication  plan. 
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Initiate  Software  Process  Improvement 
Educate  and  Build  Support 


Tasks 


•  Briefing  kits  for  communication  sessions 

•  Build  (or  obtain)  a  series  of  briefings  that  can  be  tailored  to  var¬ 
ious  organization  components  covering  what  the  effort  is  all 
about,  why  it  is  being  initiated,  how  it  will  affect  the  audience, 
and  what  the  desired  outcomes  are. 

•  Develop  a  briefing  plan  to  cover 

Senior  managers  and  their  staff. 

Software  managers  and  their  staff. 

Software  practitioners. 

Corporate  senior  managers  (if  applicable). 

•  Enlist  key  stakeholders  to  deliver  briefings  where  possible  or  ap¬ 
propriate. 

•  Brief  organization  in  as  many  different  forums  as  possible. 

Establish  dialogues  with  key  stakeholders  during 
briefings  to  help  form  the  SPI  program. 

Follow  up  with  key  stakeholders  to  get  feedback  and 
buy-in. 
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1.5  Obtain  Approval  for  Proposal  and  Initial 

Resources 


Purpose  Present  the  SPI  proposal  to  senior  management  and  get  their  approv¬ 

al  and  allocation  of  time  and  resources  necessary  to  launch  the  SPI 
program. 

There  may  be  some  iteration  from  Step  1.1,  Get  Started  (page  14) 
through  this  step  (1.5)  until  agreement  is  reached  on  the  proposal 
and  resources  to  continue  or  abandon. 

Objectives  •  Obtain  approval  and  resources  from  senior  management  and 

buy-in  from  other  key  stakeholders. 

•  Obtain  resources  for  SEPG. 

•  Obtain  senior  management  time  participation  in  follow-on  activ¬ 
ities  (MSG,  assessing  climate,  launching  SPI,  etc.). 

Entry  Criteria  •  Business  rationale  for  establishing  a  SPI  program  is  clear. 

The  proposal  is  completed  and  ready  to  be  delivered. 

Exit  Criteria  •  Proposal  approved  and  resources  allocated. 

or 

•  Proposal  rejected  and  program  cancelled. 

Outputs  •  Approved  proposal. 

Allocated  resources. 

•  Updated  organization  communication  plan. 

Tasks  •  Present  the  proposal  to  the  key  organization  stakeholders  and  se¬ 

nior  management. 

•  Obtain  approval  of  the  proposal. 

•  Allocate  initial  resources  to  begin  work  (primarily  the  SEPG  at 
this  point). 
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1.5  Obtain  Approval  for  Proposal  and  Initial  Resources 


Establish  funding  strategy  (identify  who  is  responsible  for  pro¬ 
viding  and  managing  what  resources). 

Budget  for  needed  resources. 

Find/obtain/distribute  resources,  including  senior  management 
time  to  participate  in  follow-on  activities. 

Update  the  organization  communication  plan. 
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1.6  Establish  the  Software  Process  Improvement 

Infrastructure 


Overview  To  effectively  manage  the  SPI  program,  an  infrastructure  must  be  in 

place  or  created.  The  elements  of  the  infrastructure  must  have  clear¬ 
ly  defined  duties  and  responsibilities  along  with  authority  to  proper¬ 
ly  ensure  the  success  of  the  SPI  program.  Appendix  B.0,  Compo¬ 
nents  of  the  Software  Process  Improvement  Infrastructure,  on 
page  159  describes  the  process  improvement  infrastructure  in  more 
detail. 


The  primary  purpose  for  establishing  an  infrastructure  for  a  SPI  pro¬ 
gram  is  to  build  the  mechanisms  necessary  to  help  the  organization 
institutionalize  continuous  process  improvement. 

The  infrastructure  established  with  any  SPI  program  is  critical  to  the 
success  of  that  program.  A  solid,  effective  infrastructure  can  sustain 
a  developing  SPI  program  until  it  begins  to  produce  visible  results. 
A  good  infrastructure  can  mean  the  difference  between  a  successful 
SPI  program  and  a  failure.  Unsupported  SPI  programs  can  become 
isolated  and  die  out  during  periods  of  stress  and  tension  within  their 
organizations. 

Infrastructure  concepts  apply  to  both  local  (site)  SPI  programs  and 
to  corporate  programs  that  consist  of  many  different  sites,  each  run¬ 
ning  its  own  local  SPI  program.  When  the  individual  SPI  programs 
are  a  part  of  a  larger  organization,  there  are  activities  that  can  be 
done  and  mechanisms  that  can  be  established  that  will  help  ensure 
that  the  individual  programs 

•  Survive  and  are  effective. 

Provide  economies  of  scale  with  reduced  site  costs. 

•  Enhance  sharing  of  lessons  learned  across  multiple  sites. 

The  infrastructure  will  validate  the  program  and  lend  credence  to  the 
efforts.  The  infrastructure  will  guide  and  monitor  the  SPI  program 
and  facilitate  allocation  of  resources.  The  infrastructure  will  also  in- 
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1.6  Establish  the  Software  Process  Improvement  Infrastructure 


Purpose 


teract  with  external  groups  to  maintain  an  awareness  of  the  state  of 
the  practice  relating  to  process  improvement. 

When  establishing  the  SPI  infrastructure,  the  size,  structure,  and  cul¬ 
ture  of  the  organization  undertaking  the  SPI  must  be  considered. 
This  along  with  any  geographic  considerations  will  guide  the  cre¬ 
ation  of  the  SPI  infrastructure  so  that  management’s  view  of  the  SPI 
program  is  absolutely  clear. 

At  the  core  of  the  improvement  infrastructure  is  the  software  engi¬ 
neering  process  group  (SEPG)  that  facilitates  the  SPI  program. 
There  should  also  be  a  local  MSG  to  advise  the  SEPG  and  monitor 
its  efforts.  For  larger  organizations  that  span  multiple  sites,  or  for  ef¬ 
forts  that  span  several  organizations,  a  representative  from  each  of 
the  SEPGs  or  MSGs  should  meet  to  coordinate  process  improve¬ 
ment  activities  across  several  SEPGs.  In  very  large  organizations, 
there  should  be  an  executive  council  (EC)  to  deal  with  strategy 
and  direction  for  the  organization’s  SPI  program.  Technical  work¬ 
ing  groups  (TWGs)  or  process  action  teams  (PATs)  will 
come  and  go,  existing  for  finite  periods  of  time  to  accomplish  their 
goals.  These  different  entities  are  further  described  in  Appendix  B.0, 
Components  of  the  Software  Process  Improvement  Infrastructure 
(page  159),  which  also  includes  sample  charters  for  each  entity. 

SPI  is  a  significant  undertaking  for  an  organization,  and  it  is  almost 
impossible  to  accomplish  anything  without  a  supporting  infrastruc¬ 
ture.  The  infrastructure  will  do  a  lot  of  things  for  the  SEPGs  and 
TWGs  that  are  on  the  front  lines  trying  to  accomplish  process  im¬ 
provement.  The  infrastructure  can 

Provide  resources  when  they  are  needed. 

Provide  counseling  about  the  direction,  scope,  and  speed  of  the 
effort. 

•  Clear  the  way  so  the  SPI  program  proceeds  smoothly. 

•  Maintain  visibility  for  the  SPI  program. 

•  Facilitate  and  encourage  information  sharing. 

•  Retain  lessons  learned  and  improvements  developed. 

Provide  a  support  resource. 
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Initiate  Software  Process  Improvement 

Establish  the  Software  Process  Improvement  Infrastructure 


Objectives 


Entry  Criteria 
Exit  Criteria 


Figure  1-2  on  page  28  shows  these  elements  as  they  support  SPI. 

•  Establish  the  infrastructure. 

•  Start  ongoing  infrastructure  activities: 

Facilitate  the  SPI  program. 

Advise  and  monitor  the  efforts  of  the  SEPG. 

Coordinate  process  improvement  activities. 

Provide  visible  and  effective  sponsorship  for  the  SPI 
program 

SPI  Proposal  approved  and  resources  allocated. 

•  Infrastructure  defined  in  terms  of  specific  people,  organizational 
entities,  roles  and  responsibilities,  and  interfaces. 

•  Infrastructure  in  place  and  operating. 

Although  the  task  of  establishing  the  infrastructure  has  a  definite  ex¬ 
it,  many  of  the  activities  that  are  begun  in  this  task  start  continuous, 
ongoing  activities  that  last  for  the  life  of  the  SPI  program. 
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28 
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1.6  Establish  the  Software  Process  Improvement  Infrastructure 


Tasks 


The  subtasks  for  Step  1 .6,  Establish  the  Software  Process  Improve¬ 
ment  Infrastructure,  are 


Subtask 

Page 

Number 

1.6.1:  Establish  the  Management  Steering  Group  (MSG) 

30 

1 .6.2:  Establish  the  Software  Engineering  Process  Group  (SEPG)  (Responsibility  of 
MSG) 

31 

1 .6.3:  Maintain  Visibility 

32 

1.6.4:  Facilitate  and  Encourage  Information  Sharing 

34 

1.6.5:  Retain  Lessons  Learned  and  Improvements  Developed 

36 

1.6.6:  Provide  a  Support  Network 

38 
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Establish  the  Management  Steering  Group  (MSG) 


1.6.1 


Establish  the  Management  Steering  Group  (MSG) 


If  a  similar  group  already  exists,  revise/expand  their  charter  to  re¬ 
flect  this  new  responsibility.  See  Appendix  B.0,  Components  of  the 
Software  Process  Improvement  Infrastructure  (page  159),  for  more 
information  on  the  various  infrastructure  entities  and  their  defini¬ 
tions. 

•  Select  members,  chairperson. 

•  Define  roles  and  responsibilities. 

•  Define  relationship  with  the  SEPG,  TWGs  and  other  parts  of  the 
organization,  including  reporting  requirements. 

•  Develop/revise  charter  for  MSG. 

Conduct  team  building  for  MSG  (and  between  MSG  and  any 
other  entities  defined). 
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1.6.2  Establish  the  Software  Engineering  Process  Group 

(SEPG)  (Responsibility  of  MSG) 

If  a  similar  group  already  exists,  revise/expand  their  charter  to  re¬ 
flect  this  new  responsibility.  See  Appendix  B.0,  Components  of  the 
Software  Process  Improvement  Infrastructure  (page  159),  for  more 
information  on  the  various  infrastructure  entities  and  their  defini¬ 
tions. 

•  Determine  SEPG  member  qualifications. 

•  Select  SEPG  members. 

•  Define  SEPG  roles  and  responsibilities. 

•  Refine  relationship  with  MSG. 

•  Define  relationships  with  TWGs  and  the  rest  of  the  organization, 
including  reporting,  tracking,  and  support  requirements. 

Select  SEPG  leader  (if  not  already  assigned;  likely  to  be  SPI 
champion). 

•  Develop  SEPG  charter. 

•  Start  team  building  for  the  SEPG. 
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1.6.3 


Maintain  Visibility 


Purpose  The  purpose  of  maintaining  visibility  of  a  SPI  program  is  to 


•  Keep  senior  management  attention  focused  on  the  long-term 
program. 

•  Provide  information  to  the  organization  as  a  whole  to  see  the  ef¬ 
fort  and  progress  of  the  SPI  program. 

•  Provide  ongoing  recognition  of  what  is  happening  within  the  SPI 
program  as  it  evolves. 

SPI  programs  are  launched  and  sponsored  by  executive  manage¬ 
ment,  but  they  are  often  forgotten  or  become  invisible  after  the  ini¬ 
tial  fanfare  is  over.  Having  a  regular  time  set  aside  at  all  levels  of 
management  for  paying  attention  to  the  SPI  program  keeps  the  pro¬ 
gram  in  focus  and  maintains  its  visibility.  This  will  enable  manage¬ 
ment  to  respond  to  situations  that  arise  at  individual  sites  before 
these  situations  approach  crisis  proportions.  Successes  can  be 
shared,  and  a  common  vision  and  approach  to  the  SPI  program  can 
be  developed  across  the  entire  organization. 

Maintaining  visibility  of  the  SPI  program  and  its  activities  is  crucial 
to  the  survival  of  the  program.  During  the  early  part  of  the  program, 
the  SPI  program  does  not  provide  highly  visible  results.  There  is  a 
tendency  to  lose  sight  of  the  objectives  and  long-term  nature  of  the 
SPI  program,  especially  during  periods  of  organizational  upheaval 
and  crisis.  Quite  often  SPI  programs  die  through  neglect  rather  than 
deliberate  termination,  as  individuals  become  more  concerned  and 
involved  with  day-to-day  crises  and  lose  focus  on  the  long-term  ben¬ 
efits. 

This  activity  is  initiated  once  the  organization  has  decided  to  under¬ 
take  a  SPI  program.  The  activity  will  remain  active  for  the  duration 
of  the  SPI  program.  In  the  early  stages  of  the  SPI  program,  this  ac¬ 
tivity  consists  in  building  an  awareness  and  generating  support  for 
the  undertaking.  While  the  improvement  program  is  under  way  this 
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Objectives 


Entry  Criteria 
Tasks 


Validation 


activity  serves  to  continuously  reinforce  the  benefits  of  the  SPI  pro¬ 
gram. 

•  Keep  all  levels  of  management  informed  on  the  issues,  progress, 
and  results  of  the  SPI  program. 

•  Keep  the  entire  organization  informed  on  the  progress  and 
results  of  the  SPI  program. 

•  Publicly  recognize  efforts  of  individuals  and  teams  in  the  SPI 
program. 

SPI  program  under  way 

•  Conduct  management  briefings  and  reviews. 

•  Establish  organization-wide  communication  vehicles  (such  as 
newsletters,  town-hall  type  meetings,  brown  bag  seminars)  to 
keep  the  entire  organization  informed  on  the  progress  and  results 
of  the  SPI  program. 

•  Establish  a  recognition  program  that  publicly  demonstrates  re¬ 
wards  for  SPI  efforts  and  results. 

•  Survey  the  organization  to  determine  the  effectiveness  of  com¬ 
munications. 


Exit  Criteria  The  program  must  maintain  visibility  of  its  efforts  throughout  its 

lifetime.  There  is  no  exit  from  communicating  progress  and  results 
unless  the  entire  program  is  tenninated. 

Specific  messages  must  be  effectively  communicated.  The  organiza¬ 
tion  should  be  periodically  surveyed  to  ensure  that  the  messages  are 
being  received. 
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1.6.4  Facilitate  and  Encourage  Information  Sharing 


Purpose  The  busier  SPI  programs  get,  the  less  time  there  is  to  share  informa¬ 

tion  between  the  SEPG  and  the  rest  of  the  organization,  especially 
those  not  directly  involved  in  a  SPI  program,  and  between  other 
SEPGs  in  the  organization.  Sometimes  these  organizations  are  solv¬ 
ing  some  of  the  same  or  related  problems,  or  breaking  the  same 
ground  on  how  to  become  more  effective  in  their  SPI  work.  More 
formal  mechanisms  to  facilitate  and  encourage  information  sharing 
can  help. 

The  purpose  of  such  mechanisms  is  simply  to  cause  information  to 
be  shared  in  a  regular,  structured  fashion  so  that  such  exchanges  do 
not  get  lost  in  the  day-to-day  business  of  the  SPI  program. 

There  are  two  main  dimensions;  local  (site  information  sharing)  and 
global  (infonnation  sharing  between  organizations).  Local  informa¬ 
tion  is  shared  through  a  variety  of  means  such  as  monthly  newslet¬ 
ters,  brown  bag  lunches,  attendance  by  the  SEPG  at  various  staff 
meetings,  etc.  Global  information  is  shared  by  holding  periodic 
meetings  (at  least  quarterly)  where  the  SEPGs  from  different  orga¬ 
nizations  are  brought  together,  preferably  away  from  their  work  en¬ 
vironments,  with  a  structured  agenda  to  share  lessons  learned,  prob¬ 
lems  encountered,  and  successes.  Where  several  SEPGs  are  close  to 
each  other  geographically,  local  software  process  improve¬ 
ment  networks  (SPINs)  may  be  a  vehicle  for  information  shar¬ 
ing.  These  usually  meet  monthly. 

Objectives  •  Establish  periodic,  planned  SPI  program  meetings  to  share  infor¬ 

mation  locally  about  effective  practices  and  leam  from  others’ 
efforts. 

•  Establish  periodic,  planned  cross-organizational  meetings  of 
SEPGs  to  share  information  globally  about  effective  practices 
and  progress,  and  to  leam  from  other  organizations. 

Entry  Criteria  •  SPI  program  under  way. 
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•  For  multi-organizational  sharing,  more  than  one  organization 
must  have  a  SPI  program  under  way. 

Tasks  •  The  local  SEPG  sets  up  periodic  (perhaps  quarterly)  meetings 

that  the  key  participants  in  the  SPI  program — MSG  members, 
TWG  leaders,  process  owners  and  architects,  and  pilot  project 
leaders — attend. 

A  corporate  SEPG  sets  up  periodic  (perhaps  annual)  meetings  to 
bring  the  various  local  SEPGs  together. 

•  Incentives  and  recognition  are  provided  for  participating  in  local 
and  global  meetings. 

Validation  •  Survey  meeting  participants  for  effectiveness  of  presentations, 

sharing,  and  practices. 

•  Track  long-term  usage  of  practices  to  see  how  widely  they  are 
adopted. 

Exit  Criteria  As  long  as  the  SPI  programs  are  running  in  organizations,  informa¬ 

tion  should  be  shared  among  the  various  participants. 

Meetings  should  occur  at  frequent  enough  intervals  that  practices 
can  be  shared  before  they  are  reinvented. 
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1.6.5  Retain  Lessons  Learned  and  improvements  Developed 


Purpose  While  the  information-sharing  activities  described  previously  facil¬ 

itate  sharing  of  lessons  learned,  successes,  and  typical  problems  and 
their  resolution,  they  only  do  so  for  the  immediate  time  frame.  As 
SEPGs  evolve  and  personnel  rotate,  these  lessons  become  lost  and 
forgotten,  and  the  SEPGs  find  themselves  “reinventing  the  wheel” 
when  they  run  into  the  same  or  similar  problem  later. 


The  SPI  program  must  establish  or  integrate  with  an  existing  long¬ 
term  memory  capability  to  facilitate  the  organization’s  continued 
growth  and  maturity.  To  achieve  this,  creation  of  a  repository  or  pro¬ 
cess  database  is  vital.  This  is  a  mechanism  where  lessons  learned, 
successes,  and  examples  of  the  artifacts  coming  out  of  SPI  programs 
are  maintained  and  distributed.  Infonnation  should  be  regularly  cap¬ 
tured  on  such  things  as 

•  The  process  for  SPI. 

Processes  and  products  produced. 

•  Examples  of  artifacts  generated  during  a  SPI  program  (for 
example,  action  plans). 

Solutions  developed  and  how  they  were  applied. 

In  addition  to  being  used  to  collect  information,  the  samples  collect¬ 
ed  should  be  transformed  into  generic  templates,  and  the  lessons 
learned  folded  into  some  continuously  updated  approach  that  is  dis¬ 
seminated  to  all  SPI  participants.  This  kind  of  activity  can  be  done 
within  the  SEPG  on  a  local  basis,  or  may  require  some  focused  cor¬ 
porate  resources  to  be  effective.  For  most  effective  corporate -wide 
learning,  all  sites  should  contribute  to  and  draw  from  the  collective 
repository.  In  the  absence  of  a  corporate-wide  effort,  local  SEPGs 
could  still  perform  this  function  for  their  organizations. 
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Objectives 


Entry  Criteria 


Tasks 


Validation 


Exit  Criteria 


•  Establish  criteria  and  processes  for  information  gathering  and  re¬ 
tention. 

•  Collect  and  disseminate  lessons  learned. 

Develop  generic,  reusable  components  of  SPI  program. 

SPI  program  under  way. 

•  Local  SEPG  established. 

•  SPI  program  has  infonnation  to  share. 

•  Establish  criteria  for  information  to  retain. 

•  Establish  processes  for  collecting,  cataloging,  and  disseminating 
information. 

•  Create  SPI  repository 

•  Collect  and  catalog  process  infonnation  and  lessons  learned. 

•  Periodically  publish  index  of  materials  in  repository. 

Derive  generic  components  (templates,  tools,  methods,  etc.)  for 
reuse  by  other  SPI  programs. 

•  Disseminate  lessons  learned  and  generic  components  to  all  SPI 
participants. 

Publicize  use  of  repository  items  by  using  success  stories,  recog¬ 
nition  programs,  etc. 

Track  usage  of  components,  requests  for  types  of  information, 
inflow  and  outflow  of  information,  and  other  measures  that  indi¬ 
cate  effectiveness  of  the  repository. 

Ultimately,  assess  whether  the  repository  gets  used,  stays  cur¬ 
rent,  and  becomes  part  of  the  standard  operating  environment  of 
the  organization. 

The  collection  and  dissemination  of  infonnation  about  SPI  must 
continue  as  long  as  the  organization  wants  to  continue  to  leam  from 
and  improve  on  its  past  efforts  and  not  lose  organizational  memory. 
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1.6.6  Provide  a  Support  Network 


Purpose  For  most  organizations,  SPI  is  a  new  activity;  thus  new  knowledge, 

skills,  and  behaviors  must  be  learned  and  some  old  ways  of  doing 
things  stopped.  This  requires  personal  as  well  as  organizational 
change,  and  the  people  involved  need  support  to  keep  making 
progress  in  learning  new  ways  of  doing  things. 


With  an  informal,  peer-to-peer  support  network  established,  SEPGs 
and  other  SPI  participants  can  go  directly  to  their  peers  in  other  or¬ 
ganizations  or  at  other  sites  to  get  advice  and  support.  They  can  find 
qualified,  experienced  people  to  help  fill  the  gaps  where  they  might 
not  have  sufficient  resources  to  do  something.  They  can  call  on  their 
peers  to  get  advice  and  try  out  their  ideas. 

To  make  this  effective,  they  have  to  know  their  peers  and  trust  them. 
They  may  start  to  build  a  “super”  team  consisting  of  SEPGs  across 
all  sites,  establishing  an  infonnal  network  of  SPI  programs.  This 
cannot  be  accomplished  just  through  information- sharing  mecha¬ 
nisms.  Deliberate  team  building  activities  should  be  planned  and  co¬ 
ordinated.  Some  mechanisms  that  have  been  used  effectively  are 

•  Common  training. 

•  Collaboration  on  assessments. 

•  Joint  process  improvement  projects  across  the  organization. 

With  a  corporate  SPI  infrastructure,  there  are  opportunities  for  econ¬ 
omies  of  scale  that  are  not  available  in  a  single-site  activity.  If  a  ma¬ 
jority  of  the  members  of  a  single  site  SEPG  leave  for  some  reason, 
usually  the  group  must  go  outside  for  new  training  and  orientation. 
The  group  may  even  have  to  back  up  several  steps  and  start  again 
with  all  the  facilitation  and  support  provided  at  their  start-up.  This 
can  become  very  expensive  over  a  large  number  of  sites, 
especially  in  an  environment  in  which  people  regularly  rotate  as¬ 
signments,  or  in  which  staff  downsizing  is  occurring.  Furthermore, 
SEPG  members  at  a  single  site  have  to  translate  all  advice  from  their 
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Objectives 


Tasks 


Validation 


Exit  Criteria 


facilitators  and  teachers  to  their  context  and  have  to  keep  calling  on 
that  initial  start-up  support  organization  for  assistance  and  advice. 

•  Establish  a  broad,  informal,  company-wide  network  of  SEPGs. 

•  Establish  programs  and  mechanisms  for  SEPGs  to  work 
together. 

•  Provide  common  training  for  all  SEPGs. 

•  Plan  supporting  activities  between  SEPGs  (such  as  collaboration 
on  assessments  and  joint,  cross-organizational  improvement 
projects). 

•  Create  a  directory  of  SEPG  members  across  the  company  and 
their  specific  areas  of  expertise. 

•  Local  SEPG  members  know  where  to  get  help  outside  their  or¬ 
ganizations. 

•  SEPG  members  spend  some  amount  of  time  outside  their  home 
organizations  helping  other  SEPGs. 

This  activity  must  continue  as  long  as  the  various  SEPG  members 
across  the  company  need  support,  which  is  likely  to  be  as  long  as 
their  own  program  is  running. 
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1.7  Assess  the  Climate  for  SPI 


Purpose  The  purpose  of  assessing  the  climate  for  SPI  is  to  identify  barriers 

and  leverage  points  across  the  organization  that  will  affect  the  SPI 
program,  and  to  develop  effective  plans  to  ensure  that  the  improve¬ 
ments  made  during  the  SPI  program  last. 

A  substantial  portion  of  this  task  is  based  on  concepts  of  managing 
technological  change. 

Objectives  •  Identify  key  organizational  barriers  to  a  SPI  program. 

•  Define  strategies  to  interact  with  other  related  programs  and  in¬ 
itiatives. 

•  Define  strategies  to  reduce  those  barriers. 

Develop  a  strategy  and  plan  for  developing  sponsorship,  com¬ 
munications,  and  change  agent  abilities. 

Entry  Criteria  •  SEPG  members  have  taken  a  course  in  Managing  Technological 

Change  (Table  1-2  on  page  9). 

•  The  infrastructure  has  been  defined  in  terms  of  specific  people, 
organizational  entities,  roles  and  responsibilities,  and  interfaces. 

•  The  infrastructure  is  in  place  and  operating. 

Exit  Criteria  •  Assessments  are  complete. 

•  Sponsorship  development  plans  and  organization  communica¬ 
tion  plan  have  been  completed. 

•  Interfaces  and  interactions  with  other  programs  and  initiatives 
have  been  defined. 

•  Change  management  strategy  developed. 

Outputs  •  Change  management  assessment  results  and  strategies. 

•  Organization  communication  plan  and  sponsorship  development 
plans. 
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•  Assess  the  past  history  and  barriers  to  implementing  similar 
change  programs. 

•  Assess  the  organization’s  culture  and  identify  related  barriers 
and  leverage  points. 

•  Assess  sponsorship  for  SPI  and  determine  what  is  needed  to  im¬ 
prove  it. 

•  Assess  current  resistance  to  a  new  SPI  program  and  identify  re¬ 
lated  barriers  and  leverage  points. 

•  Identify  what  other  improvement  activities  and  major  develop¬ 
ments  are  already  occurring  and  determine  how  to  interface  and 
interact  with  them. 

•  Develop  change  management  strategies  to  reduce  or  remove  bar¬ 
riers,  capitalize  on  leverage  points,  cascade  sponsorship  for  SPI, 
manage  target  resistance  to  changes,  and  generally  increase  the 
organization’s  capacity  for  change. 

•  Develop  an  organization  communication  plan  including  messag¬ 
es,  audiences,  media,  sequencing,  and  monitoring  to  implement 
the  change  management  strategies. 
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1.8  Launch  the  Program 


Purpose  The  purpose  of  this  activity  is  to  move  into  the  main  part  of  the  SPI 

program  and  start  the  continuous  cycle  of  the  process  improvement 
program. 

Usually  this  begins  with  an  “SEPG  kickoff’  workshop  that  refreshes 
the  memory  of  the  MSG  and  SEPG  members  about  what  the  road¬ 
map  is  and  what  kinds  of  things  the  SEPG  and  MSG  will  have  to  do 
in  subsequent  steps. 

Objectives  •  Transition  from  initial  activities  to  ongoing  activities. 

Entry  Criteria  •  Program  proposal  approved. 

•  Sponsorship  and  organization  communication  strategy  and  plans 
completed. 

•  Interfaces  and  interactions  with  other  programs  and  initiatives 
defined. 

•  Infrastructure  established  in  terms  of  specific  people,  organiza¬ 
tional  entities,  roles  and  responsibilities,  and  interfaces. 

Exit  Criteria  •  Program  and  infrastructure  in  place  and  operating. 

•  Agreement  and  approval  to  move  to  next  step,  2.0,  Manage  the 
Software  Process  Improvement  Program. 

Tasks  •  Learn  about  the  SPI  techniques  and  process  selected.  (Conduct 

an  “SEPG  kickoff’  workshop) 

Review  the  SPI  proposal. 

•  Review  organizational  assessment  results  (from  Step  1 .7,  Assess 
the  Climate  for  SPI). 

•  Review  interaction  plans  for  other  programs  and  initiatives. 

•  Obtain  senior  management  approval  to  move  to  the  next  step, 
2.0,  Manage  the  Software  Process  Improvement  Program. 
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2.0  Manage  the  Software  Process 

Improvement  Program 


Overview  At  the  initiation  of  the  SPI  program,  the  initial  SPI  infrastructure  was 

put  in  place  to  manage  the  activities  that  the  organization  would  be 
undertaking  during  its  SPI  program.  Now  that  some  time  has  passed 
and  the  initial  accomplishments  of  building  support,  obtaining  spon¬ 
sorship,  gaining  commitment,  completing  the  maturity  assessment, 
completing  action  planning,  and  defining  baselines  has  been  com¬ 
pleted,  it  is  a  good  time  to  review  how  well  the  infrastructure  that 
was  set  up  has  performed. 


Some  questions  to  answer  about  the  performance  of  the  infrastruc¬ 
ture  that  was  initially  put  in  place  are 

•  Has  the  infrastructure  effectively  linked  the  SPI  program  to  the 
organization’s  mission  and  vision? 

•  Has  the  infrastructure  been  able  to  obtain  and  allocate  sufficient 
resources  to  ensure  timely  accomplishments? 

•  Has  the  infrastructure  monitored  the  SPI  program  properly  and 
provided  guidance  and  correction  as  necessary? 

As  the  organization  moves  from  the  initial  baselining  phase  of  the 
SPI  program  into  the  improvement  implementation  phase,  it  is  crit¬ 
ically  important  to  have  in  place  a  strong,  responsive,  and  supportive 
infrastructure.  Any  fine  tuning  or  adjustments  to  the  infrastructure 
should  be  made  at  this  time,  before  beginning  the  next  phase. 

The  improvement  activities  will  not  occur  in  a  vacuum  nor  will  they 
occur  in  a  serial  fashion.  Once  the  SPI  program  is  under  way,  there 
will  be  multiple  improvement  activities  occurring  across  different 
organizational  units.  For  example,  there  may  be  technical  working 
groups  (TWGs)  addressing  configuration  management,  require¬ 
ments  management,  project  planning,  and  peer  reviews  all  active  si¬ 
multaneously.  The  infrastructure  must  keep  track  of  all  this  and  be 
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prepared  to  provide  the  required  oversight  and  guidance  to  the  ef¬ 
forts. 

The  supporting  infrastructure  must  be  aware  that  TWGs  can  and 
probably  will  operate  in  parallel.  At  any  time,  the  improvement  in¬ 
frastructure  must  be  prepared  to 

Offer  support  for  a  technology  being  introduced. 

•  Coordinate  training  resources. 

Continue  to  build  and  provide  sponsorship. 

•  Provide  planning  expertise. 

•  Assess  organizational  impact. 

Show  lessons  learned. 

In  short  the  infrastructure  must  perfonn  many  management  func¬ 
tions  for  the  organization  as  it  progresses  with  the  SPI  program. 

Tasks  The  subtasks  for  Step  2.0,  Manage  the  Software  Process  Improve¬ 

ment  Program,  are 


Subtask 

Page 

Number 

2.1:  Setting  the  Stage  for  Software  Process  Improvement 

45 

2.2:  Organizing  the  SPI  Program 

48 

2.3:  Planning  the  SPI  Program 

55 

2.4:  Staffing  the  SPI  Program 

58 

2.5:  Monitoring  the  SPI  Program 

60 

2.6:  Directing  the  SPI  Program 

65 
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2.1  Setting  the  Stage  for  Software  Process 

Improvement 


Purpose  Once  the  SPI  program  is  started,  management  has  the  most  challeng¬ 

ing  and  in  some  sense  the  most  rewarding  responsibility.  Significant 
challenges  will  come  from  the  organization’s  resistance  to  change, 
cost,  and  the  schedule  demands  and  inevitable  slow  progress  that 
seem  to  characterize  all  improvement  efforts.  Management  must 
keep  the  SPI  program  focused  on  improvements  connected  to  the  or¬ 
ganization’s  vision  and  mission. 


To  keep  the  SPI  program  focused  over  the  long  tenn,  a  management 
infrastructure  will  be  required.  This  management  infrastructure  will 
have  to  make  changes  of  focus  and  adjustments  to  priorities  many 
times  as  the  effort  proceeds.  These  changes  will  be  driven  by  both 
internal  and  external  factors,  changes  in  the  marketplace,  shortage  of 
resources,  critical  skill  availability,  availability  of  new  or  improved 
technologies,  and  any  of  a  host  of  other  factors. 

One  of  the  biggest  challenges  that  the  management  infrastructure 
will  have  to  deal  with  is  the  organization  itself.  The  organization  has 
a  culture,  and  the  SPI  program  in  some  cases  will  be  asking  this  cul¬ 
ture  to  change.  Guiding  an  organization  through  a  change  in  culture 
takes  time. 

A  significant  challenge  related  to  dealing  with  the  organization  is 
management  itself.  Management  must  be  able  to  recognize  that  they 
are  a  significant  part  of  the  organizational  culture  and  that  they  may 
also  be  required  to  change  as  the  organization  changes. 

Managers  must  be  able  to  divorce  themselves  from  cultural  biases 
and  organizational  biases  and  be  aware  of  the  differing  perspectives 
from  different  groups  that  make  up  the  organization.  They  must 
work  to  integrate  these  different  groups  into  the  SPI  program,  build¬ 
ing  consensus  and  support  for  the  SPI  program  as  they  proceed. 

As  the  organization  progresses  through  the  SPI  program,  new  or  dif¬ 
ferent  technologies  will  be  introduced  to  effect  the  improvements.  A 
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problem  will  arise  not  from  these  new  or  different  technologies,  but 
from  the  fact  that  the  organization  itself  will  be  required  to  go 
through  a  transition  as  these  new  or  different  technologies  are  intro¬ 
duced. 

The  difficulty  in  introducing  a  new  technology  lies  not  in  the  fact 
that  the  technology  is  new  but  in  the  fact  that  the  technology  will  re¬ 
quire  change.  Change  is  the  culprit.  As  new  or  different  technology 
is  introduced  during  the  SPI  program,  people  will  be  asked  to  do 
their  jobs  differently,  work  with  different  equipment,  work  with  dif¬ 
ferent  tools,  or  possibly  change  positions  within  the  organization. 
People  will  be  asked  to  move  out  of  their  comfort  zone  into  some¬ 
thing  that  is  unknown  to  them. 

It  is  a  very  common  occurrence  within  an  improvement  effort  to  re¬ 
quire  people  to  change  the  way  they  currently  do  their  work,  and  it 
is  also  a  very  common  and  natural  thing  for  people  to  resist  the 
change.  Why  should  they  change  something  that  they  have  grown 
comfortable  with  for  something  that  is  unknown  to  them?  The  man¬ 
agement  infrastructure  should  be  prepared  for  and  expect  resistance 
to  the  improvement  initiative.  Regardless  of  whether  the  improve¬ 
ments  are  viewed  as  a  good  thing  or  a  bad  thing,  there  will  still  be 
change  and  there  will  be  resistance. 

Being  able  to  recognize  that  this  resistance  to  the  changes  that  man¬ 
agement  requires  is  occurring  and  being  able  to  deal  with  it  effec¬ 
tively  is  critical  to  the  success  of  the  SPI  program. 

The  type  and  amount  of  resistance  will  vary  from  organization  to  or¬ 
ganization,  depending  on  the  culture  that  exists  within  the  organiza¬ 
tion. 

Resistance  will  occur  in  two  forms:  overt  and  covert.  It  is  easier  for 
management  to  deal  with  the  overt  resistance,  as  it  is  out  in  the  open 
and  easily  recognized.  The  harder  challenge  will  be  to  surface  covert 
resistance  so  that  it  is  more  recognizable  and  easier  to  deal  with.  Be¬ 
ing  aware  that  resistance  will  occur — that  it  is  not  always  on  the  sur¬ 
face — and  being  able  to  recognize  it  when  it  is  surfaced  will  make 
things  go  a  lot  smoother.  However  managing  the  SPI  program  will 
still  be  a  difficult  challenge. 

Objectives  •  Establish  priorities  for  the  SPI  program. 
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•  Approve  SPI  strategic  action  plans. 

•  Allocate  resources. 

•  Monitor  improvement  progress  against  plan. 

Develop  reward  system. 

Provide  continuing,  visible  sponsorship. 

Entry  Criteria  •  Commitment  made  to  establish  and  implement  a  software  pro¬ 

cess  improvement  (SPI)  program. 

Proposal  for  SPI  program  completed  and  approved. 

•  Resources  for  SPI  program  authorized. 

Business  needs  identified. 

Tasks  •  Review  and  select  baselines  that  are  needed. 

•  Review  resource  requirements  for  the  SPI  program. 

•  Tailor  roadmap  activities  as  appropriate  for  the  organization. 
Develop  sponsorship  activities. 

•  Introduce  concepts  of  managing  technological  change  and 
technology  transition. 

•  Obtain  training  on  ability  to  recognize  and  deal  with  obstacles 
that  will  present  themselves  to  the  improvement  program. 


CMU/SEI-95-UG-001 


47 


2.0  Manage  the  Software  Process  Improvement  Program 
2.2  Organizing  the  SPI  Program 


2.2  Organizing  the  SPI  Program 


Purpose  As  a  SPI  program  gets  under  way,  an  infrastructure  must  be  devel¬ 

oped  and  put  in  place.  This  infrastructure  will  have  the  responsibility 
of  providing  guidance  for  the  SPI  program. 


In  most  cases  there  will  be  three  components  to  the  organization’s 
SPI  infrastructure: 

1 .  Software  engineering  process  group  (SEPG). 

2.  Management  steering  group  (MSG). 

3.  Technical  working  group  (TWG). 

These  are  generic  names  and  may  vary  from  organization  to  organi¬ 
zation.  The  components  of  the  infrastructure  and  their  relationship 
to  each  other  are  largely  determined  by  such  factors  as  organization 
size  and  geographical  diversity.  Figure  2-1  below  is  an  illustration 
of  the  components  of  a  typical  SPI  infrastructure. 
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First  and  most  important  is  the  software  engineering  process 
group  (SEPG),  sometimes  called  the  process  group.  The  SEPG 
performs  many  functions  for  the  organization  in  its  SPI  programs. 

The  SEPG 

•  Helps  to  sustain  support  for  the  SPI  program  in  an  environment 
of  change. 

•  Builds  and  reinforces  sponsorship. 

•  Nurtures  and  sustains  the  individual  improvement  activities. 

•  Ensures  coordination  of  these  activities  throughout  the 
organization. 

The  SEPG  is  chartered  by  the  MSG.  This  charter  acts  as  the  contract 
between  management  and  the  SEPG.  The  charter  typically  outlines 
the  role,  responsibility,  and  authority  of  the  SEPG. 

It  cannot  be  emphasized  too  strongly  that  the  SEPG  is  not  the  imple¬ 
mentor  of  the  improvements.  The  role  of  the  SEPG  is  that  of  a  facil¬ 
itator,  helping  to  guide  the  process  improvement  activity.  The  SEPG 
also  plays  a  support  role,  helping  the  projects  with  any  difficulties 
that  they  may  encounter  as  they  implement  process  improvement. 

In  most  cases  members  of  the  SEPG  are  recruited  from  the  organi¬ 
zation’s  existing  staff  of  software  engineering  professionals.  The 
support  that  the  organization’s  management  demonstrates  for  the 
SPI  program  will  influence  the  ability  to  recruit  quality  people  for 
membership  in  the  SEPG. 

Membership  in  the  SEPG  is  on  both  a  full-time  and  a  part-time  basis. 
Obviously,  it  is  most  desirable  to  have  all  members  of  the  SEPG 
dedicated  100%,  but  this  is  not  always  achievable  in  practice.  Part- 
time  members  can  be  used  for  periods  of  time  when  the  SEPG  has  a 
lot  of  activity  occurring  for  a  finite  period  of  time.  It  is  strongly  rec¬ 
ommended  that  the  organization  have  at  least  one  person  dedicated 
full  time  to  the  SEPG  and  that  he  or  she  be  the  SEPG  leader. 

Characteristics  of  a  typical  member  of  the  SEPG  include 

•  Experience  as  a  practitioner. 

•  Expert  knowledge  in  one  or  more  domains. 

•  Good  interpersonal  skills. 
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•  Respect  of  their  peers  in  the  organization. 

It  will  be  a  difficult  task  to  draw  these  people,  who  are  some  of  the 
best  and  the  brightest  that  the  organization  has,  away  from  a  project 
manager  who  has  responsibility  for  a  critical  project. 

Some  staff  will  want  to  become  members  of  the  SEPG.  The  ease 
with  which  staff  can  be  recruited  will  depend  on  the  perceived  level 
of  management  support  for  the  SPI  program.  Projects  may  lose  some 
of  their  best  people  to  the  SEPG.  This  must  be  allowed  to  happen, 
though.  The  organization  should  not  sacrifice  long-term  gain  for  the 
organization  as  a  whole  in  favor  of  short-term  gain  for  an  individual 
project. 

In  the  long  run,  the  organization  must  do  all  it  can  to  ensure  the  suc¬ 
cess  of  the  SPI  program;  yet  this  has  to  be  balanced  against  the  needs 
of  the  individual  projects.  The  SEPG  candidates  must  support  the 
SPI  program,  be  willing  to  act  as  champions  for  the  SPI  program, 
and  be  willing  to  serve  as  agents  of  change  to  the  rest  of  the  organi¬ 
zation. 

The  leader  of  the  SEPG  must  be  a  respected  member  of  the  organi¬ 
zation  with  proven  ability.  The  SEPG  leader  should  also  have  the 
confidence  of  his  or  her  peers  and  be  looked  on  as  someone  who  can 
get  things  done.  The  SEPG  leader  also  must  have  the  support  and 
confidence  of  senior  management. 

In  some  instances  organizations  have  written  formal  job  descriptions 
describing  the  duties  and  responsibilities  of  an  SEPG  member.  They 
then  have  posted  the  open  positions  for  all  to  see  and  review, 
screened  applications,  and  conducted  a  rigorous  interview  process  in 
selection  of  the  personnel  to  staff  the  SEPG.  By  doing  the  staffing  in 
this  manner,  management  sends  a  clear  message  to  the  organization 
about  their  view  of  the  importance  of  the  SPI  program. 

The  SEPG  will  report  on  their  activities  to  the  second  component  of 
the  infrastructure,  the  management  steering  group  (MSG).  Addition¬ 
al  names  for  the  MSG  include  quality  management  board  and  pro¬ 
cess  improvement  steering  committee.  The  MSG  is  responsible  for 
linking  the  SPI  program  to  the  organization’s  vision  and  mission. 

Some  of  the  duties  of  the  MSG  include 
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•  Demonstrating  sponsorship  for  the  SPI  program. 

•  Allocating  resources  for  the  improvement  activities. 

•  Monitoring  the  progress  of  the  SPI  program. 

•  Providing  guidance  and  correction  to  the  improvement  activities 
as  necessary. 

Membership  of  the  MSG  is  made  up  of  the  senior  manager  as  leader 
and  selected  members  of  his  or  her  management  team  making  up  the 
rest  of  the  group.  This  team  makes  up  a  standing  committee,  meeting 
regularly  to  address  matters  relative  to  the  SPI  program.  The  MSG 
usually  meets  monthly,  but  in  the  early  stages  of  a  SPI  program  it 
may  meet  more  frequently  to  insure  a  proper  start. 

The  third  main  component  of  the  SPI  infrastructure  is  the  technical 
working  groups  (TWGs).  Additional  names  for  these  groups  include 
process  action  teams  and  process  improvement  teams. 

These  working  groups  are  created  to  address  a  particular  focus  of  the 
SPI  program.  For  example,  there  could  be  a  configuration  manage¬ 
ment  TWG  or  a  project  planning  TWG  addressing  a  specific  soft¬ 
ware  engineering  domain.  Also  the  TWGs  do  not  necessarily  have 
to  address  technical  domains  for  improvement — they  could  address 
such  things  as  travel  reimbursement,  software  standardization,  or 
purchasing,  for  example. 

The  TWG  is  typically  made  up  of  those  practitioners  in  the  organi¬ 
zation  who  have  knowledge  and  experience  of  the  area  under  evalu¬ 
ation.  Membership  will  also  include  those  who  would  be  affected  by 
any  improvement  changes  that  would  be  implemented  as  a  result  of 
the  investigation. 

The  TWGs  typically  have  a  finite  life,  the  duration  of  which  is  usu¬ 
ally  defined  in  the  charter.  After  the  completion  of  the  TWG  objec¬ 
tive,  it  is  disbanded,  and  the  members  return  to  their  normal  duties. 

During  the  early  phases  of  the  SPI  program,  issues  of  scope  usually 
cause  TWGs  to  underestimate  the  time  required  to  complete  their 
objectives.  This  results  in  TWGs  going  back  to  the  MSG  requesting 
more  time  or  a  reduced  scope.  Knowledge  gained  from  TWG  expe¬ 
rience  will  reduce  these  occurrences  as  the  scope  of  the  working 
groups  comes  to  be  more  specifically  defined. 
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The  TWGs  report  to  the  MSG.  At  the  monthly  meeting  that  the  MSG 
holds,  the  agenda  will  always  include  a  status  briefing  from  each  of 
the  active  TWGs.  The  TWGs  also  have  a  dotted  line  reporting  rela¬ 
tionship  to  the  SEPG.  This  allows  the  SEPG  to  fulfill  its  charter  of 
being  the  focal  point  for  process  improvement  for  the  organization 
by  keeping  abreast  of  the  improvement  activities  that  are  under  way 
in  the  organization.  This  also  allows  the  SEPG  to  create  a  repository 
of  artifacts  that  have  been  produced  and/or  used  during  the  improve¬ 
ment  process.  This  repository,  also  called  the  process  database, 
contains  records  of  the  data  gathered  and  generated  during  the  im¬ 
provement  process.  This  process  database  provides  a  ready  refer¬ 
ence  for  measuring  results  of  the  SPI  program.  It  also  provides  a 
mechanism  for  familiarizing  new  personnel  with  the  operation  as 
they  join  the  SPI  program.  Physically  the  process  database  will  prob¬ 
ably  be  a  combination  of  artifacts  in  file  drawers,  multiple  fonns  of 
data  held  in  some  machine  readable  form  that  belongs  to  the  SEPG, 
and/or  such  things  as  electronic  mail  messages. 
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Objectives 


Entry  Criteria 


Additional 

Components 


•  Establish  infrastructure  to  guide  and  manage  the  SPI  program. 

•  Create  organizational  awareness  of  the  SPI. 

•  Commitment  to  establish  and  implement  a  SPI  program. 

SPI  strategic  action  plan  in  place,  agreed  upon,  and  approved. 

In  some  instances  benefit  can  be  gained  from  having  additional  com¬ 
ponents  to  the  SPI  infrastructure.  Typically  these  additional  compo¬ 
nents  are  formed  in  organizational  environments  that  are  either  very 
large  and/or  have  wide  geographical  disbursement. 

The  first  of  these  additional  components  is  an  executive  council 
(EC).  Members  of  the  EC  are  made  up  of  the  senior  management 
from  each  division.  The  EC  provides  broad  guidance  and  interpreta¬ 
tion  of  the  organization’s  vision  and  mission  and  communicates  this 
interpretation  to  the  divisions.  At  the  division  level,  it  is  the  respon¬ 
sibility  of  the  MSG  for  the  division  to  ensure  that  the  improvement 
activities  in  each  division  are  responsive  to  the  organization’s  vision 
and  mission  as  provided  by  the  EC. 

The  second  additional  component  is  usually  called  something  simi¬ 
lar  to  software  process  improvement  advisory  committee 
(SPIAC).  This  committee  is  usually  created  when  an  organization 
has  multiple  SEPGs  resulting  in  multiple  improvement  efforts  oc¬ 
curring  across  different  locations  within  the  organization.  The  rea¬ 
sons  for  having  multiple  SEPGs  are  typically  a  consequence  of  the 
organization’s  size  and/or  geographic  disbursement  of  the  organiza¬ 
tion. 

The  SPIAC  serves  as  a  forum  where  each  of  the  multiple  SEPGs  are 
represented.  Through  this  forum,  sharing  of  experiences,  lessons 
learned,  and  improvements  accomplished  will  benefit  the  overall 
program.  A  forum  in  which  SEPGs  can  exchange  information  reduc¬ 
es  the  number  of  false  starts  so  that  SEPGs  do  not  have  to  duplicate 
work  that  other  SEPGs  have  already  done. 

Figure  2-2  below  illustrates  how  an  improvement  infrastructure 
might  look  in  a  very  large  organization. 
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Figure  2-2:  Typical  SPI  Infrastructure  in  a  Large  Organization 

Tasks  •  Establish  the  MSG. 

•  Establish  the  SEPG. 

•  Develop  charter  for  the  SEPG  (MSG). 

•  Demonstrate  sponsorship  for  the  improvement  activities. 

•  Develop  charter  template  for  the  TWGs. 
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2.3  Planning  the  SPI  Program 


Purpose  Software  process  improvement  will  be  a  significant  undertaking  for 

an  organization.  To  coordinate  the  many  activities  that  will  occur  in 
the  course  of  a  SPI  program  requires  an  effective  infrastructure  for 
support.  Additionally,  the  infrastructure  must  be  able  to  react  in  a 
timely  manner  to  the  demands  of  the  SPI  program. 


There  are  many  plans  that  will  be  developed  to  guide  and  support  the 
SPI  program.  Strategic  plans  are  the  responsibility  of  management; 
tactical  plans  to  address  specific  improvement  activities  are  the  re¬ 
sponsibility  of  the  TWGs.  There  are  also  installation  plans  for  pilot 
adoption  activity,  and  plans  for  rollout  and  installation  of  improved 
processes  on  a  broad  scale.  Each  of  these  plans  will  have  schedules 
that  must  be  monitored  and  defined  milestones  that  must  be  re¬ 
viewed.  These  schedules  and  milestones  will  be  used  to  evaluate 
progress  toward  a  specific  objective. 

To  decide  on  and  introduce  improvement,  the  current  organizational 
practices,  used  in  creating  the  work  product,  must  be  researched  and 
evaluated  so  that  they  are  fully  understood  and  documented.  Also  to 
be  considered  is  what  would  be  the  impact  of  change  in  this  partic¬ 
ular  area,  trying  to  recognize  potential  impacts  as  early  as  possible 
so  they  can  be  dealt  with  up  front  and  in  a  timely  fashion. 

To  help  understand  the  current  practices,  techniques  are  available  to 
model  and  assess  the  current  practice.  This  will  define  and  document 
the  “as  is”  state.  To  determine  the  areas  for  improvement,  the  “as  is” 
candidate  processes  must  be  screened  and  evaluated.  After  this  eval¬ 
uation,  information  regarding  the  candidate  improvement  technolo¬ 
gies  should  be  gathered  and  shared  so  that  informed  decisions  can  be 
made  for  selecting  the  candidate  processes  to  improve  and  the  can¬ 
didate  technology  to  be  used  for  the  improvement. 

Developing  the  plans  for  the  improvement  activities  starts  with  a  re¬ 
view  of  the  findings  and  recommendations  that  resulted  from  the 
software  process  maturity  assessment.  This  input,  along  with  input 
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from  any  organizational  maturity,  process,  or  metrics  baselining  ac¬ 
tivities  that  have  been  recently  completed,  provides  the  starting 
point  for  development  of  the  SPI  strategic  action  plan.  These  inputs 
along  with  the  knowledge  of  and  interpretation  of  the  organization’s 
vision  and  mission  will  help  detennine  the  content,  priority,  and  se¬ 
quence  of  activities  for  the  SPI  program. 

One  of  the  continuing  activities  of  an  improvement  program  is  build 
and  maintain  sponsorship  and  support  for  the  initiative.  To  help  ac¬ 
complish  this  objective,  it  would  be  beneficial  to  the  program  to  find 
and  fix  a  few  quick- fix,  quick-retum  improvement  projects — pick¬ 
ing  the  so-called  “low-hanging  fruit.”  Implementing  these  quick-fix 
improvements  and  communicating  their  occurrence  will  have  many 
benefits.  It  will  help  demonstrate  to  personnel  within  the  organiza¬ 
tion  the  value  of  the  initiative  by  showing  some  immediate  benefit. 
It  will  also  help  create  enthusiasm  and  support  for  the  initiative. 

The  SEPG  works  at  both  the  tactical  level  and  the  strategic  level 
within  the  SPI  program,  but  it  will  probably  concentrate  most  of  its 
efforts  at  the  tactical  level,  addressing  issues  that  arise  as  the  SPI 
program  proceeds. 

There  will  be  many  plans  developed,  modified,  discarded,  and  com¬ 
pleted  as  the  SPI  program  proceeds,  as  business  conditions  change, 
and  as  personnel  and  organizational  changes  occur.  The  SPI  strate¬ 
gic  action  plan,  developed  as  a  result  of  the  maturity  assessment  and 
other  baselining  activities,  will  be  the  overall  guide  to  the  SPI  pro¬ 
gram.  Subordinate  plans  will  include 

•  Plans  for  how  the  infrastructure  will  work. 

•  Plans  and  charters  for  the  TWGs  that  will  investigate  and 
provide  solutions  within  a  specific  problem  area. 

•  Plans  for  pilot  introduction  of  new  or  changed  technologies. 

•  Plans  for  wide-scale  introduction  and  initiation  of  piloted 
changes. 

•  Plans  on  how  to  adopt  and  institutionalize  proven  improvement 
accomplishments. 

Appendix  A.0,  Taxonomy  of  Software  Process  Improvement  Plans 
and  Charters  (page  145)  lists  and  describes  plans  that  are  used  in  a 
SPI  program.  Appendix  C.0,  Charters  and  Templates  (page  175)  has 
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Objectives 


Entry  Criteria 


Tasks 


an  assortment  of  sample  plans,  templates,  and  charters  along  with 
some  discussion  of  their  use  and  application. 

•  Define  goals  of  the  SPI  program. 

•  Provide  focus  and  direction  for  the  SPI  activities. 

•  Determine  resources  required  for  the  SPI  program. 

•  Show  commitment  for  the  SPI  program. 

•  MSG  established. 

•  SEPG  established. 

•  Organizational  strategic  business  plan  exists. 

•  Review  baselines  and  select  which  baselines  to  develop. 

•  Plan  for  and  schedule  training  required  for  the  selected  baselines 
and  strategic  planning  activities. 

•  Develop  organizational  plan  for  the  SPI  program. 

•  Develop  SPI  strategic  action  plan. 

•  Based  on  results  from  the  baselining  activities,  develop  tactical 
action  plans. 

Develop  detailed  schedules  through  completion  of  baselining 
and  strategic  planning. 

Review  and  approve  plans  developed  (MSG) 


CMU/SEI-95-UG-001 


57 


2.0  Manage  the  Software  Process  Improvement  Program 
2.4  Staffing  the  SPI  Program 


2.4  Staffing  the  SPI  Program 


Purpose  In  most  cases  existing  people  resources  will  be  used  to  staff  the  SPI 

program.  These  resources  will  include  those  that  are  allocated  to  the 
improvement  work  itself  and  those  that  are  assigned  to  the  SPI  infra¬ 
structure  to  guide  and  manage  the  SPI  program. 


In  addition  to  the  resources  devoted  to  the  management  structure, 
additional  resources  allocated  to  the  SPI  program  take  two  forms. 

The  first  are  people  resources  that  are  allocated  full  time  and  make 
up  the  SEPG.  Staff  to  fill  the  positions  in  the  SEPG  will  usually 
come  from  the  practicing  professionals  within  the  organization’s  de¬ 
velopment  ranks.  The  success  of  the  SEPG  and  the  effectiveness  of 
the  SPI  program  depend  largely  on  the  quality  of  the  people  that  staff 
the  SEPG. 

The  SEPG  is  a  small  organization;  typically  it  has  a  staff  size  that  is 
equal  to  1%  to  3%  of  the  organization’s  practitioner  head  count.  Oc¬ 
casionally,  extra  resources  will  be  needed  for  some  specific  tasks. 
To  provide  these  additional  resources  for  the  SEPG  when  required, 
there  may  be  some  temporary  members  assigned  to  the  SEPG.  These 
assignments  are  usually  for  a  finite  period  of  time,  allowing  the 
members  enough  time  to  complete  their  specific  task  before  return¬ 
ing  to  their  previous  duties. 

A  second  set  of  resources  will  be  required  to  staff  the  TWGs  that  will 
be  formed  to  address  specific  improvement  issues.  Resources  for  the 
TWGs  are  usually  committed  as  a  percent  of  a  full-time  person;  for 
example,  “John,  we  would  like  you  to  spend  20%  of  your  time  for 
the  next  8  months  working  on  the  TWG  that  is  solving  our  require¬ 
ments  management  problem.”  These  resources  are  committed  for  a 
finite  length  of  time,  usually  defined  in  the  TWG  charter,  and  are  as¬ 
signed  very  specific  responsibilities  within  the  SPI  program  by  the 
MSG. 

A  TWG  will  be  formed  by  the  MSG,  given  its  specific  charter  and 
goals.  When  its  tasks  are  completed,  the  TWG  will  be  disbanded. 
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There  are  some  instances  in  which  a  TWG  is  active  continuously, 
usually  addressing  broader  issues  and  consuming  a  smaller  percent¬ 
age  of  members’  time. 

Typically  TWG  membership  will  rotate  among  the  staff.  This  will 
allow  the  organization  to  provide  fresh  insight  into  the  problem¬ 
solving  process  and  also  allow  more  personnel  to  become  further  ex¬ 
posed  to  and  become  a  part  of  the  SPI  program. 

The  last  component  of  the  SPI  infrastructure  that  will  need  resources 
assigned  to  it  is  the  MSG. 

For  the  most  part,  resources  assigned  to  the  MSG  come  from  the  or¬ 
ganization’s  existing  management  structure,  although  it  is  not  un¬ 
heard  of  to  have  input  from  the  customer  community. 

In  most  cases  each  major  component  of  the  organization  is  repre¬ 
sented  on  the  MSG  by  at  least  one  member,  and  leadership  of  the 
MSG  is  provided  by  the  senior  executive.  Additionally  the  SEPG  is 
typically  represented  on  the  MSG  by  the  SEPG  leader,  usually  in  a 
non-voting  capacity. 

Objectives  •  Assign  management-level  staff  to  the  MSG. 

•  Recruit  qualified  staff  for  SEPG  membership. 

•  Recruit  and/or  assign  proper  representation  to  TWGs. 

Entry  Criteria  •  MSG  established. 

•  SEPG  established. 

Tasks  •  Assign  management  staff  to  the  MSG. 

•  Create  job  descriptions  for  the  SEPG  members. 

•  Recruit  staff  for  the  SEPG. 

Develop  guidelines  for  TWG  membership. 

•  Recruit  and/or  assign  staff  to  the  TWGs. 

•  Review  resource  requirements  for  each  baselining  activity 
against  resources  available. 
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2.5  Monitoring  the  SPI  Program 


Purpose  As  the  SPI  program  proceeds,  one  of  the  responsibilities  of  the  MSG 

will  be  to  periodically  review  progress  of  the  initiative  against  the 
milestones  and  goals  that  are  defined  and  documented  in  the  SPI 
strategic  action  plan.  These  progress  reviews  of  the  SPI  program  will 
be  regularly  scheduled,  and  occur  at  the  monthly  meeting  of  the 
MSG. 


The  format  that  the  reviews  will  take  should  be  defined  in  advance 
by  the  MSG,  documented  in  the  TWG  charter  and  should  be  the 
same  from  review  to  review.  It  may  take  a  few  cycles  of  review 
meetings  to  determine  the  most  productive  format  for  the  review  and 
any  associated  artifacts  that  are  used  or  distributed  at  the  review. 

Evaluation  activities  encompass  all  facets  of  an  organization’s  SPI 
program.  Evaluations  ask  such  questions  as 

•  Are  we  doing  it  right? 

•  Are  we  doing  the  right  thing? 

Have  we  achieved  the  expected  benefits? 

•  Are  the  improvement  projects  on  schedule? 

To  monitor  the  SPI  program,  a  measurement  system  to  evaluate 
progress  must  be  in  place.  The  key  to  evaluating  the  SPI  program 
will  be  the  metrics  that  are  selected  for  measurement  and  the  ease 
with  which  they  can  be  gathered.  Measurement  will  occur  at  many 
levels  throughout  the  organization — from  very  low-level  measure¬ 
ments  such  as  coding  errors  that  are  found  during  inspections  or  test¬ 
ing  to  higher  level  measures  such  as  the  rate  and/or  volume  of  field 
trouble  calls.  All  these  measures  should  be  maintained  so  that  a  his¬ 
tory  of  the  benefits  of  the  SPI  program  will  be  available  when  need¬ 
ed. 

There  are  generally  two  fonns  of  evaluation  of  the  SPI  program. 
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Manage  the  Software  Process  Improvement  Program 
Monitoring  the  SPI  Program 


Objectives 


Entry  Criteria 


Micro-Evaluation 


1 .  Micro-level  evaluation,  whose  parameters  are  defined  during  the 
baselining  and  planning  activities.  This  micro-level  evaluation 
deals  with  such  things  as  project  schedules,  milestones,  process 
performance,  process  quality,  and  other  quantitative  measures. 

2.  Macro-level  evaluation,  which  deals  with  broader,  more  qualita¬ 
tive  issues  such  as  business  issues,  business  value,  competitive 
factors,  market  conditions,  etc. 

Ensure  that 

•  Improvement  activity  is  consistent  with  corporate  objectives. 

•  Plans  for  the  SPI  program  are  being  followed. 

•  Progress  toward  improvement  goals  is  being  made. 

TWGs  are  defined  and  operational. 

Working  group  plans  have  been  developed  and  approved. 

The  infrastructure  evaluates  the  SPI  program  at  the  micro  level  by 
measuring  progress  of  the  SPI  program  quantitatively.  This  evalua¬ 
tion  includes  the  existing  process  and  technologies  and  also  the  ex¬ 
pectations  from  new  or  different  processes  and  technologies  not  yet 
in  use  by  the  organization  but  being  considered  for  adoption. 

Process  perfonnance  also  should  be  evaluated.  The  effectiveness  of 
old  and/or  existing  processes  should  have  some  type  of  metric  that 
can  easily  be  applied  to  determine  whether  or  not  these  processes  are 
contributing  to  the  overall  mission  of  the  organization.  Processes 
should  also  be  measured  to  enable  comparison  of  current  perfor¬ 
mance  to  new  performance  when  new  or  improved  processes  are  im¬ 
plemented.  Once  new  processes  are  implemented,  they  should  be 
continuously  monitored  and  their  performance  evaluated  to  ensure 
that  the  benefits  expected  from  their  introduction  are  being 
achieved. 

Quality  performance  of  the  processes  is  also  evaluated  at  the  micro 
level.  During  the  baselining  process  and  during  the  development  of 
plans  for  new  or  revised  processes,  quality  expectations  and  quality 
metrics  are  defined  and  implemented  within  the  processes  to  verify 
their  benefits.  Later,  as  the  processes  are  implemented,  a  longer 
range  comparison  of  expected  or  planned  results  can  be  made. 
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The  monitoring,  evaluating,  and  reporting  on  process  quality  and  ef¬ 
fectiveness  is  typically  the  responsibility  of  the  software  quality  as¬ 
surance  group.  The  SEPG  will  play  a  supporting  role  in  this  effort. 
The  SEPG  will  not  be  the  only  group  assisting  in  this  effort.  Project 
staff  will  also  provide  input  regarding  quality  and  effectiveness  of 
processes  used  in  the  development  activity. 

Working  groups  will  provide  input  about  expectations  for  new  pro¬ 
cesses  being  introduced  and  the  quality  and  effectiveness  of  existing 
processes  that  they  are  investigating. 

At  the  micro  level  of  evaluation,  members  of  the  SEPG,  quality  as¬ 
surance  personnel,  the  TWGs,  and  the  project  staff  are  responsible 
for  evaluating  the  performance  of  the  process  and  recommending 
and  applying  control  mechanisms  to  achieve  the  expected  results. 

Macro-Evaluation  Evaluations  of  the  SPI  program  at  the  macro  level  tend  to  be  more 

qualitative  and  are  therefore  the  responsibility  of  the  MSG. 

When  they  design  the  new  processes,  the  SEPGs,  TWGs,  and 
projects  must  consider  the  criteria  that  management  needs  to  make 
these  more  qualitative  evaluations  at  the  macro  level.  Management 
will  also  consider  criteria  that  is  input  from  other  sources  such  as 
market  information,  competitive  infonnation,  vision  and  mission  in¬ 
terpretations,  and  input  from  the  general  business  environment. 

Monitoring  the  SPI  program  and  applying  proper  control  procedures 
will  ensure  that  the  goals  and  objectives  of  the  program  are  being 
met.  It  will  also  ensure  that  the  program  is  consistent  with  corporate 
strategies.  Each  component  of  the  infrastructure  must  periodically 
review  its  own  progress  and  also  review  the  progress  of  its  subordi¬ 
nate  organizations. 

Individual  improvement  efforts  are  evaluated  in  the  review  meetings 
that  have  been  defined  and  documented  in  the  schedules. 

Periodically  reviewing  the  progress  of  the  improvement  program  en¬ 
ables  detection  of  early  warning  signals  that  can  indicate  that  the 
program  is  off  track.  Two  key  questions  should  be  asked  at  each  of 
the  program  reviews: 

1 .  Are  we  meeting  the  milestones  set  for  this  individual  program? 
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2.  Are  the  programs  consistent  with  the  strategic  direction  of  the 
corporation? 

The  format  that  the  reviews  will  take  should  be  defined  in  advance 
by  the  MSG  and  should  be  the  same  from  review  to  review. 

The  plans  that  are  developed  to  guide  the  improvement  activities 
will  include  a  schedule  of  milestones,  scheduled  review  meetings, 
and  defined  deliverables.  The  regularly  scheduled  in-process  re¬ 
views  will  compare  progress  against  the  previously  agreed-upon 
schedules.  In  this  manner  the  MSG  will  be  able  to  get  early  warning 
of  any  difficulty  occurring  within  the  SPI  program  and  be  able  to 
provide  corrective  action. 

After  evaluating  available  technology  and  selecting  a  technology  to 
use  for  improvement,  an  approach  for  introducing  the  selected  tech¬ 
nology  must  be  fonnalized.  This  includes  obtaining  sponsorship, 
planning  the  implementation,  evaluating  risk,  and  selling  the  new 
technology  to  pilot  users.  After  selecting  the  pilot  and  testing  the 
technology  and  approach  to  implementation  with  the  pilot,  the  re¬ 
sults  are  evaluated.  This  evaluation  answers  these  questions: 

Did  the  new  technology  improve  the  process  it  was  selected  to 
improve? 

•  Are  there  any  downstream  impacts  that  were  not  planned  for? 

•  What  lessons  were  learned  in  the  pilot  that  can  be  applied  so  that 
implementation  has  minimal  impact? 

From  the  lessons  learned  with  the  pilot,  the  implementation  ap¬ 
proach  is  revised  for  wide-scale  adoption.  The  revised  plan  from  the 
pilot  is  used  to  introduce  the  technology  on  a  broader  scale  across 
the  organization. 

During  the  time  that  the  implementation  has  been  occurring  across 
the  organization,  a  support  mechanism  for  the  new  technology  must 
be  established.  Also  at  this  time,  lessons  learned  during  the  adoption 
and  institutionalization  process  should  be  documented  and  analyzed. 
These  are  retained  in  the  process  database  for  use  in  future  adoption 
and  institutionalization  activities. 

From  time  to  time,  course  correction  or  change  of  focus  of  the  SPI 
program  may  be  necessary,  for  such  reasons  as  business  opportuni- 


CMU/SEI-95-UG-001 


63 


2.0  Manage  the  Software  Process  Improvement  Program 
2.5  Monitoring  the  SPI  Program 


Tasks 


ty,  organizational  or  personnel  changes,  funding  issues,  and  others. 
This  is  not  unusual  and  should  not  be  cause  for  dismay.  By  having 
scheduled,  periodic  reviews  of  the  activities  of  the  SPI  program,  the 
MSG  will  be  able  to  provide  the  necessary  guidance  and  be  able  to 
make  informed  decisions  regarding  the  overall  effort  at  the  earliest 
opportunity. 

Define  procedures  for  SPI  status/progress  reviews. 

Develop  schedule  for  SPI  status/progress  reporting  meetings. 

•  Review  progress  against  SPI  strategic  action  plan. 

•  Review  process  perfonnance  against  plan. 

•  Review  strategic  direction. 
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2.6  Directing  the  SPI  Program 


Purpose  The  SPI  program  needs  direction  on  two  levels — strategic  and  tacti¬ 

cal.  The  strategic-level  direction  insures  that  the  overall  goals  of  the 
organization  will  be  met.  The  tactical-level  direction  insures  that 
specific  improvement  activity,  consistent  with  the  strategic  goals,  is 
accomplished.  The  MSG  is  charged  with  providing  this  direction  to 
the  effort. 


At  the  strategic  level,  the  MSG  must  ensure  that  the  SPI  efforts  are 
linked  to  the  organization’s  overall  vision  and  mission.  Working  at 
this  strategic  level,  the  MSG  is  concerned  with  a  broad  set  of  issues 
that  can  affect  the  SPI  program.  Some  additional  areas  for  review 
and  evaluation  include  market  opportunities,  organizational  struc¬ 
ture,  technology  advances,  available  resources,  etc. 

Some  of  the  responsibilities  include 

•  Reviewing  and  linking  together  the  existing  policies  of  the 
organization. 

•  Evaluating  how  these  existing  policies  help  or  hinder  the  SPI 
program  and  how  they  integrate  with  the  overall  vision  and 
mission. 

The  MSG  must  tie  all  this  together.  Integrating  all  of  this  with  the 
findings  from  the  assessment  and  baselining  efforts  is  a  critical  step 
in  determining  the  priorities  of  the  SPI  program. 

Direction  at  the  tactical  level  is  focused  on  getting  the  proven  im¬ 
provement  activities  completed  and  institutionalized.  The  MSG 
must  resolve  any  and  all  impediments  discovered  during  the  evalu¬ 
ation  of  existing  organization  policy  and  procedures.  After  evaluat¬ 
ing  existing  and  planned  baselines,  the  MSG  will  also  determine  and 
set  priorities  for  the  activities  that  will  address  the  findings  from  the 
assessment  and  baselining. 

TWGs  must  be  chartered  to  address  specific  areas  that  have  been 
previously  agreed  upon  and  prioritized  by  the  MSG.  The  charters 
that  will  be  developed  must  be  drafted  so  that  the  schedule,  mile- 
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Objectives 

Tasks 


stones,  and  resources  are  understood  by  all  members  of  the  TWG. 
Additionally  the  progress  reporting  requirements  should  be  defined 
and  scheduled  for  the  duration  of  the  TWG. 

Directing  the  activities  of  the  SPI  program  will  not  be  as  easy  as  it 
appears.  For  example,  there  can  be  minor  changes  made  in  a  specific 
department  that  do  not  appear  to  have  much  impact.  But,  a  different 
department  might  use  the  work  product  of  the  department  that  made 
the  change,  and  might  rely  on  things  being  done  the  old  way  to  get 
its  job  done  properly.  Consideration  must  be  given  to  the  way  in 
which  changes  in  one  area,  no  matter  how  minor,  can  have  a  ripple 
effect  on  the  entire  organization. 

Such  events  can  be  prevented  by  making  sure  that  the  proper  people 
are  represented  on  the  TWGs  and  that  changes  are  piloted  in  a  con¬ 
trolled  setting  before  being  released  across  the  organization.  The 
working  group  should  include  users  of  the  process,  suppliers  to  the 
process,  and  receivers  of  the  finished  product.  By  itself  this  will  not 
ensure  that  the  problem  will  be  solved,  but  it  will  significantly  re¬ 
duce  its  chance  of  occurring. 

Ensure  that  SPI  program  direction  is  consistent  with  the  organiza¬ 
tion’s  vision  and  mission. 

Review  existing  policies  and  procedures. 

•  Evaluate  existing  policies  and  procedures  to  determine  priorities 
for  establishing  TWGs. 

•  Authorize  and  initiate  TWGs  as  required. 

•  Evaluate  criteria  and  make  informed  decisions  regarding  priority 
and  direction  of  SPI  program. 
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3.0  Build  Software  Process 

Improvement  Strategy 


Overview  This  step  is  one  of  the  most  critical  in  the  roadmap — and  most  often 

neglected.  This  is  where  the  management  team  develops  or  updates 
a  software  process  improvement  (SPI)  strategic  action  plan,  based 
on  the  organization’s  vision,  strategic  business  plan,  and  past  im¬ 
provement  efforts.  This  is  a  step  that  is  repeated  as  needed.  Usually 
it  is  triggered  by  a  lack  of  a  strategic  improvement  plan  for  an  orga¬ 
nization  on  its  first  cycle  through  this  roadmap.  For  those  organiza¬ 
tions  on  a  subsequent  cycle,  this  step  can  be  triggered  by  a  need  to 
update  the  previous  plan,  goals,  or  directions. 


This  process  is  the  responsibility  of  the  management  steering  group 
(MSG).  In  a  sense,  this  is  the  creation  of  a  “management”  baseline, 
similar  to  the  more  process-oriented  or  technical  baselines  devel¬ 
oped  in  Chapter  4.0,  Baseline  Current  State  (page  99).  There  is  a 
strong  tendency  to  delegate  this  step  to  the  software  engineering  pro¬ 
cess  group  (SEPG).  Experience  has  shown,  however,  that  this  usu¬ 
ally  does  not  work.  Line  managers  must  demonstrate  their  active 
sponsorship  by  taking  the  time  to  be  actively  involved  in  developing 
this  plan,  owning  it,  and  committing  to  it.  Just  as  the  practitioners 
and  middle  managers  develop  ownership  of  the  technical  baselines 
and  issues  identified  through  their  involvement,  so  must  the  senior 
management  develop  ownership  and  consensus  on  the  directions  to 
be  taken  and  how  to  get  there.  Without  a  solid  strategy  to  guide  the 
SPI  program,  it  will  have  a  tendency  to  “drift”  with  the  problems  and 
priorities  of  the  month  (or  day  in  some  cases),  causing  the  initiative 
to  degenerate  into  not  much  more  than  another  fire-fighting  activity. 

The  MSG  begins  by  determining  what  kind  of  strategic  planning 
process  it  will  follow.  Most  organizations  have  their  favorite  ap¬ 
proach  to  strategic  planning.  Regardless  of  the  specific  method  used, 
the  important  thing  is  to  develop  a  solid  plan.  The  MSG  then  reviews 
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the  organization’s  vision,  strategic  business  plan,  past  improvement 
performance,  and  current  key  business  issues  in  order  to  detennine 
how  the  SPI  program  fits.  It  then  considers  the  results  of  baseline  ac¬ 
tivities  and  incorporates  these  results  into  the  SPI  strategic  action 
plan.  The  MSG  also  integrates  the  SPI  strategic  action  plan  with  the 
organization’s  vision  and  strategic  business  plan,  making  modifica¬ 
tions  and  revisions  as  necessary. 

The  SPI  strategic  action  plan  will  be  based  on  the  results  of  the  base¬ 
lining  efforts,  the  organization  improvement  goals,  and  the  resourc¬ 
es  available.  It  should  provide  guidance  for  the  overall  SPI  program 
and  address  how  the  long-range  organization  goals  will  be  reached. 
It  is  important  that  the  process  improvements  are  driven  by  business 
reasons,  as  opposed  to  process  improvement  for  its  own  sake.  Even 
though  the  implementation  of  process  improvement  will  usually 
have  a  heavy  staff  component,  this  cannot  turn  into  a  staff  activity. 

There  is  a  strong  temptation  at  this  point  to  immediately  begin  mak¬ 
ing  changes.  However,  the  history  of  these  kinds  of  improvement  ef¬ 
forts  has  shown  that  without  careful  planning,  the  efforts  will  even¬ 
tually  falter,  get  sidetracked,  or  will  not  meet  the  unwritten  expecta¬ 
tions  of  senior  management.  The  reason  for  the  plans  is  not  just  to 
identify  the  improvement,  but  to  meet  the  organization’s  critical 
business  needs  by  installing  those  improvements  across  the  organi¬ 
zation.  Identification  is  often  the  easiest  part.  Getting  everyone 
throughout  the  organization  to  change  the  way  they  do  things  is  al¬ 
ways  the  most  difficult  part  of  any  improvement  effort. 
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Purpose  The  purpose  of  this  step  is  to  develop  or  refine  the  SPI  strategic  ac¬ 

tion  plan  to  provide  guidance  and  direction  to  the  SPI  program  in  the 
years  to  come.  The  SPI  strategic  action  plan  is  critical  in  that  it  is 
needed  to  provide  clear  guidance  to  the  various  process  improve¬ 
ment  actions  that  will  be  taken  over  the  next  few  years.  It  should  pro¬ 
vide  clear  business  reasons  for  conducting  the  SPI  program  and 
should  be  clearly  and  measurably  linked  to  the  organization’s  strate¬ 
gic  business  plan  and  vision. 

The  primary  output  of  this  step  is  the  SPI  strategic  action  plan.  Sec¬ 
ondary  outputs  may  be  revisions  to  the  organization’s  vision  and 
strategic  business  plan. 

Objectives  The  objectives  are  to 

•  Develop/update  a  long-tenn  (three-  to  five-year)  SPI  strategic 
action  plan  that  encompasses  the  entire  organization’s  software 
process  improvement  activities  and  integrates  them  with  any 
other  total  quality  management  (TQM)  initiatives  already 
planned  or  in  process. 

•  Develop/update  long-range  (three-  to  five-year)  and  short-term 
(one-year)  measurable  goals  for  the  organization’s  SPI 
programs. 

•  Integrate  the  SPI  strategic  action  plan  with  the  organization’s 
strategic  business  plan,  mission,  and  vision. 

•  Integrate  the  baseline  findings  and  recommendations  into  the 
SPI  strategic  action  plan. 

Education/Training  The  primary  training  required  for  this  step  is  training  on  a  strategic 

planning  approach  for  the  MSG  and  the  SEPG.  Organizations  that 
do  not  have  a  satisfactory  vision  and  strategic  business  plan  may 
want  to  get  training  and  support  in  vision  development  and  strategic 
business  planning. 
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Commitment 


Communication 


Entry  Criteria 


Exit  Criteria 


Tasks 


This  step  requires  a  substantial  commitment  from  senior  manage¬ 
ment,  primarily  of  their  own  time  to  work  on  developing  the  SPI 
strategic  action  plan.  Senior  managers  must  commit  to  leading  the 
SPI  program  by  demonstrating  to  everyone  that  even  they  are  will¬ 
ing  to  take  the  time  to  develop  a  good  plan  for  their  team’s  activities 
(a  tactical  plan  for  developing  the  strategic  plan)  and  then  to  follow 
it.  In  the  process,  senior  management  should  leam  and  use  the  same 
methods  and  techniques  that  the  process  action  teams  will  have  to 
leam.  Demonstrating  visible  sponsorship  in  this  way  can  go  a  long 
way  toward  convincing  people  that  management  is  serious  about 
software  process  improvement. 

The  MSG  will  be  communicating  with  other  (non-software)  senior 
management  in  developing  objectives  and  goals.  The  baseline  teams 
will  be  reporting  issues,  results,  and  recommendations,  which  will 
support  and  be  incorporated  into  the  SPI  strategic  action  plan. 

Good  goals  are  few  in  number,  critical  to  the  organization,  highly 
visible,  and  built  with  consensus — both  horizontally  and  vertically. 
To  build  good  goals  will  require  a  substantial  amount  of  bidirection¬ 
al  communication  between  different  management  groups  and  be¬ 
tween  management  and  practitioners. 

•  A  SPI  implementation  plan  is  complete  and  approved. 

•  The  SPI  infrastructure,  particularly  the  MSG,  is  in  place  and 
operating. 

•  The  MSG  has  decided  that  the  SPI  strategic  action  plan  needs  to 
be  updated. 

•  The  SPI  strategic  action  plan  is  complete  and  approved. 

•  The  organization’s  vision,  strategic  business  plan,  and  SPI 
strategic  action  plan  are  synergistic. 

See  Figure  3-1  on  page  74  for  a  pictorial  representation  of  the  tasks. 


72 


CMU/SEI-95-UG-001 


3.0  Build  Software  Process  Improvement  Strategy 


CMU/SEI-95-UG-001 


73 


3.0 


Build  Software  Process  Improvement  Strategy 


Figure  3-1:  Process  for  Building  SPI  Strategy 
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The  subtasks  for  Step  3.0,  Build  Software  Process  Improvement 
Strategy,  are 


Subtask 

Page 

Number 

3.1:  Select  and  Get  Training  in  a  Strategic  Planning  Process 

76 

3.2:  Review  Organization’s  Vision 

77 

3.3:  Review  Organization’s  Strategic  Business  Plan 

79 

3.4:  Determine  Key  Business  Issues 

81 

3.5:  Review  Past  Improvement  Efforts 

83 

3.6:  Define  General  SPI  Goals 

84 

3.7:  Describe  the  Motivations  to  Improve 

85 

3.8:  Define  the  Guiding  Principles  of  the  SPI 

86 

3.9:  Identify  Current  and  Future  Improvement  Efforts 

87 

3.10:  Finalize  Roles  and  Responsibilities  of  the  Various  Infrastructure  Entities 

89 

3.11:  Develop  SPI  Project  Selection  Criteria  and  Process 

90 

3.12:  Put  Together  SPI  Strategic  Action  Plan  and  Determine  Baselines  Required 

91 

3.13:  Reconcile  the  Existing/Planned  Improvement  Efforts  with  the  Baseline 

Findings  and  Recommendations 

93 

3.14:  Transform  the  General  SPI  Goals  to  Specific  Measurable  Goals 

95 

3.15:  Update  the  SPI  Strategic  Action  Plan 

96 

3.16:  Build  Consensus,  Review,  and  Approve  the  SPI  Strategic  Action  Plan  and 
Commit  Resources  to  Action 

97 
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3.1 


Select  and  Get  Training  in  a  Strategic  Planning 
Process 


Purpose  The  purpose  of  this  activity  is  to  choose  a  consistent  approach  to 

strategic  planning  for  the  SPI  program  and  to  develop  skills  in  build¬ 
ing  a  solid  strategic  planning  foundation  upon  which  to  sustain  the 
SPI  program. 

Objectives  •  Select  a  strategic  planning  process. 


•  Train  the  MSG  and  SEPG  in  the  process  and  methods. 

Entry  Criteria  The  SPI  infrastructure,  particularly  the  MSG,  is  in  place  and  operat¬ 

ing  and  has  started  a  strategic  planning  effort. 


Exit  Criteria 
Tasks 


The  MSG  and  SEPG  have  completed  training  in  the  process. 

•  Review  strategic  planning  methods  already  in  use. 

•  Review  strategic  planning  needs  for  the  SPI  program. 
Select  a  strategic  planning  process  and  approach. 

•  Contract  for,  schedule,  and  hold  strategic  planning  training. 
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3.2  Review  Organization’s  Vision 


Purpose  The  purpose  of  this  activity  is  to  clearly  link  the  SPI  strategy  to  the 

organization’s  vision  and  directions  so  that  guidance  to  the  SPI  pro¬ 
gram  can  be  consistent  with  guidance  to  other  activities  within  the 
organization. 

This  activity  may  repeat  some  of  the  work  done  in  Step  1 .0,  Initiate 
Software  Process  Improvement  (page  7).  Sometimes  this  repetition 
is  not  needed,  but  often,  the  MSG  has  different  members  than  those 
who  initiated  the  SPI  program,  and  they  will  need  to  cover  some  of 
the  same  topics  to  develop  their  own  understanding  and  strategy. 
When  this  step  is  entered  as  a  result  of  a  subsequent  cycle  through 
the  improvement  roadmap,  these  topics  should  be  reviewed  at  a  min¬ 
imum. 

Objectives  •  Review  and  possibly  modify  current  vision. 

•  Generate  new  vision  if  one  does  not  exist  or  if  the  existing  one  is 
not  adequate. 

•  Identify  goals  and  motivations  for  the  SPI  program. 

Entry  Criteria  The  MSG  and  the  SEPG  have  completed  training  in  the  strategic 

planning  process. 

Exit  Criteria  •  The  SPI  strategic  goals  that  are  driven  by  the  vision  are  identi¬ 

fied. 

•  The  motivations  for  the  SPI  program  that  derive  from  the  vision 
are  identified. 

•  The  vision  and  SPI  strategy  are  synergistic. 

Outputs  •  Updated  (possibly)  vision  statement. 

•  Identified  motivations  for  improvement. 

•  Identified  SPI  strategic  goals  that  are  driven  by  the  vision. 
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3.2  Review  Organization’s  Vision 


Tasks 


Review  existing  vision  for  adequate  linkage  to  SPI  program. 
Modify  or  generate  new  vision  if  current  one  is  inadequate. 
Identify  goals  for  the  SPI  program,  based  on  the  vision. 
Identify  motivations  for  the  SPI  program  based  on  the  vision. 
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3.3  Review  Organization’s  Strategic  Business  Plan 


Purpose  The  purpose  of  this  activity  is  to  clearly  link  the  SPI  strategy  to  the 

organization’s  strategic  business  plan  so  that  guidance  to  the  SPI 
program  can  be  consistent  with  guidance  to  other  activities  within 
the  organization.  While  not  all  process  improvement  activities  can 
easily  be  linked  to  a  business  plan  or  goals,  that  does  not  mean  that 
they  are  not  needed.  Some  things  must  be  done  because  they  make 
the  business  run  better,  but  they  do  not  directly  contribute  to  the  bot¬ 
tom  line. 

This  activity  may  repeat  some  of  the  work  done  in  Step  1 .0,  Initiate 
Software  Process  Improvement  (page  7).  Sometimes  this  repetition 
is  not  needed,  but  often,  the  MSG  has  different  members  than  those 
who  set  up  the  SPI  program,  and  they  will  need  to  cover  some  of  the 
same  topics  to  develop  their  own  understanding  and  strategy.  When 
this  step  is  entered  as  a  result  of  a  subsequent  cycle  through  the  im¬ 
provement  roadmap,  these  topics  should  be  reviewed  at  a  minimum. 

Objectives  •  Review  and  possibly  modify  current  strategic  business  plan. 

•  Generate  new  strategic  business  plan  if  one  does  not  exist  or  if 
the  existing  plan  is  not  adequate. 

•  Identify  goals  and  other  (possibly  competing)  initiatives. 

Entry  Criteria  The  MSG  and  SEPG  have  completed  training  in  the  strategic  plan¬ 

ning  process. 

Exit  Criteria  •  The  SPI  strategic  goals  that  are  driven  by  the  strategic  business 

plan  are  identified. 

•  Other  improvement  efforts  that  complement  or  compete  with  the 
SPI  program  are  identified. 

•  The  strategic  business  plan  and  SPI  strategic  action  plan  are 
synergistic. 

Outputs  •  Updated  (possibly)  strategic  business  plan. 
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Review  Organization’s  Strategic  Business  Plan 


Tasks 


Identified  SPI  strategic  goals,  driven  by  the  strategic  business 
plan. 

•  Identified  other  improvement  efforts  that  affect  the  SPI  program. 

•  Review  existing  strategic  business  plan  for  adequate  linkage  to 
SPI  program. 

•  Modify  or  generate  new  strategic  business  plan  if  current  one  is 
inadequate. 

•  Identify  strategic  goals  for  the  SPI  program  driven  by  the 
strategic  business  plan. 

•  Identify  other  initiatives  that  may  support  or  compete  with  the 
SPI  program  and  the  degree  of  impact. 
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3.4  Determine  Key  Business  Issues 


Purpose  Unless  the  SPI  program  is  driven  by  the  current  business  needs  and 

understood  and  agreed  to  by  management,  it  will  likely  be  difficult 
to  sustain  the  program  over  the  long  haul.  This  is  because  it  will  be 
difficult  to  clearly  demonstrate  to  senior  management  that  the  initia¬ 
tive  is  achieving  real  value  for  the  organization  in  business  terms. 


The  key  business  needs  have  to  be  clearly  defined,  measurable,  and 
understood  to  provide  a  common  view  to  the  SPI  teams.  Improve¬ 
ments  should  be  selected  based  in  part  on  their  ability  to  satisfy  these 
business  needs.  As  described  above,  not  all  process  improvement 
activities  can  easily  be  linked  to  current  business  issues;  however  the 
business  issues  identified  should  be  used  to  prioritize  SPI  projects. 

This  activity  may  repeat  some  of  the  work  done  in  Step  1 .0,  Initiate 
Software  Process  Improvement  (page  7).  Sometimes  this  repetition 
is  not  needed,  but  often,  the  MSG  has  different  members  than  those 
who  set  up  the  SPI  program,  and  they  will  need  to  cover  some  of  the 
same  topics  to  develop  their  own  understanding  and  strategy.  When 
this  step  is  entered  as  a  result  of  a  subsequent  cycle  through  the  im¬ 
provement  roadmap,  these  topics  should  be  reviewed  at  a  minimum. 

Objectives  Determine  the  key  business  issues  driving  the  need  for  software  pro¬ 

cess  improvement. 

Entry  Criteria  The  MSG  and  SEPG  have  completed  training  in  the  process. 


Exit  Criteria 


Outputs 


Tasks 


•  The  key  business  drivers  have  been  clearly  defined. 

•  Criteria  for  prioritizing  SPI  projects  have  been  developed. 

•  Defined  and  measurable  business  needs  for  SPI. 

•  Prioritization  criteria  for  project  selection. 

•  Review  the  current  short-tenn  and  long-tenn  business  issues  as 
they  affect  SPI. 
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•  Develop  prioritization  criteria  for  selecting  and  launching  SPI 
projects,  based  in  part  on  the  identified  business  issues. 
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3.5  Review  Past  Improvement  Efforts 


Purpose  People  typically  repeat  past  behaviors,  including  both  those  that  lead 

to  success  and  those  that  do  not.  The  organization  must  learn  from 
its  past  history  and  ensure  that  this  initiative  doesn’t  repeat  past  mis¬ 
takes  that  may  have  caused  similar  initiatives  to  fail  in  the  past. 


Objectives 

Entry  Criteria 
Inputs 
Exit  Criteria 

Outputs 

Tasks 


The  information  collected  in  Step  1 .7,  Assess  the  Climate  for  SPI 
(page  40)  is  reviewed  and  analyzed,  identifying  past  change  or  im¬ 
provement  projects  and  assessing  how  successful  or  unsuccessful 
they  were  and  why. 

Review  past  change  and/or  improvement  efforts  and  identify  suc¬ 
cessful  practices  to  leverage  and  unsuccessful  practices  to  avoid. 

The  MSG  and  SEPG  have  completed  training  in  the  process. 

Assessment  from  Step  1 .7,  Assess  the  Climate  for  SPI. 

Barriers  and  leverage  points  from  past  efforts  are  identified  and 
strategies  for  reducing  the  barriers  defined  for  this  initiative. 

•  Lessons  learned  from  past  efforts. 

•  Strategies  for  overcoming  barriers. 

Identify  successful  and  unsuccessful  change  or  improvement 
projects  and  detennine  what  made  them  so. 

•  Complete  necessary  assessments  from  the  Managing 
Technological  Change  course  (if  not  already  done  in  Step  1.7, 
Assess  the  Climate  for  SPI). 

•  Define  strategies  to  deal  with  trends  and  barriers  identified. 
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3.6  Define  General  SPI  Goals 


Purpose  Improvement  is  a  long-term  investment.  Clearly  defined,  measur¬ 

able  goals  are  necessary  to  provide  guidance  and  to  assist  in  devel¬ 
oping  tactics  for  improvement.  They  also  allow  objective  measure¬ 
ment  of  the  improvement  results. 

Both  long-tenn  and  short-term  goals  are  necessary  to  focus  the  ef¬ 
fort.  The  goals  produced  at  this  point  tend  to  be  general  in  nature  un¬ 
til  sufficient  information  is  collected  to  quantity  them.  The  quantifi¬ 
cation  step  is  described  in  Step  3.12,  Put  Together  SPI  Strategic  Ac¬ 
tion  Plan  and  Determine  Baselines  Required  (page  91). 

Objectives  •  Define  long-tenn  and  short-term  goals. 

•  Determine  what  measurements  are  needed  to  objectively 
measure  the  goal. 

Entry  Criteria  •  SPI  strategy  can  be  clearly  linked  to  the  vision. 

•  SPI  strategy  can  be  clearly  linked  to  the  strategic  business  plan. 

•  The  key  business  drivers  have  been  clearly  defined. 

•  Barriers  and  leverage  points  from  past  efforts  are  identified  and 
strategies  for  reducing  the  barriers  defined. 

Inputs  •  SPI  strategic  goals  driven  by  the  vision. 

•  Lessons  learned  from  past  improvement  efforts. 

SPI  strategic  goals  driven  by  the  strategic  business  plan. 

•  Priorities  and  key  near-  and  long-term  business  issues 

Exit  Criteria  •  General  SPI  goals  defined. 

Outputs  •  SPI  strategic  action  plan  “Goals”  section. 

Tasks  Break  down  and  reconcile  goals  from  vision,  strategic  business  plan, 

key  business  issues,  and  past  history  of  improvement  efforts. 
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3.7  Describe  the  Motivations  to  Improve 


Purpose  People  must  understand  why  the  organization  is  spending  so  much 

time  and  effort  on  a  SPI  program.  They  must  be  motivated  to  join  in 
the  effort  and  assist  it. 

The  motivation  should  address  the  following  points: 

•  Why  change? 

•  What’s  wrong  with  the  status  quo? 

•  Why  should  I  care? 

•  When  will  I  be  affected  (immediately  or  sometime  in  the 
future)? 

Typically  successful  motivations  sell  the  pain  of  the  status  quo,  as 
opposed  to  selling  the  promise  of  the  desired  state. 

These  motivations  should  be  documented  in  the  SPI  strategic  action 
plan. 

Objectives  Define  motivations  for  SPI  program. 

Entry  Criteria  Motivations  identified  from  the  vision  or  similar  sources. 

Exit  Criteria  SPI  strategic  action  plan  “Motivations”  section. 

Outputs  Defined  motivations  documented  in  “Motivations”  section  of  the 

SPI  strategic  action  plan. 

Tasks  •  Build  list  of  motivations  from  the  goals  and  problems  identified 

in  previous  steps. 

•  Frame  motivations  in  tenns  of  the  difference  between  the  current 
state  and  the  desired  state. 

•  Document  motivations  in  “Motivations”  section  of  the  SPI 
strategic  action  plan. 
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3.8  Define  the  Guiding  Principles  of  the  SPI 


Purpose  The  SPI  program  can  be  used  as  a  model  and  a  mechanism  for  ex¬ 

perimenting  with  different  processes  and  behaviors  that  are  desired. 
A  typical  guiding  principle  is  to  use  the  SPI  program  to  experiment 
with  revised  management  processes,  such  as  new  forms  of  planning, 
tracking,  etc.  New  methods  can  “fail”  on  a  SPI  task  with  much  less 
dramatic  effect  on  the  organization’s  customers.  Failure  in  this  sense 
means  that  the  new  process  does  not  work  as  well  or  efficiently  as 
initially  expected — a  common  flaw  of  first-time  pilots  of  a  new  or 
revised  process. 

Any  such  guiding  principles  should  be  documented  for  people  to  use 
as  guidance  in  the  SPI  strategic  action  plan. 

Objectives  Define  guiding  principles  for  SPI  program. 

Entry  Criteria  Lessons  learned  from  past  efforts  identified. 

Exit  Criteria  Guiding  principles  defined  and  documented  in  the  “Guiding  Princi¬ 

ples”  section  of  the  SPI  strategic  action  plan. 

Outputs  SPI  strategic  action  plan  “Guiding  Principles”  section. 

Tasks  •  Review  other  organizations’ guiding  principles  for  SPI. 

Select  and  define  guiding  principles  for  the  SPI  program. 

Document  guiding  principles  in  “Guiding  Principles”  section  of 
the  SPI  strategic  action  plan. 
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3.9  Identify  Current  and  Future  Improvement  Efforts 


Purpose  Typically  most  organizations  have  many  different  improvement  ef¬ 

forts  under  way.  Often  these  initiatives  are  un-coordinated  and  com¬ 
pete  with  each  other  for  scarce  resources.  If  an  organization  is  to 
maximize  the  effectiveness  of  its  investment  in  software  process  im¬ 
provement,  it  must  evaluate  all  of  the  initiatives  under  way  and  de¬ 
termine  how  much  it  is  investing  in  each  one  and  in  total.  Resistance 
to  change  is  also  directly  correlated  with  the  total  amount  of  change 
required  of  individuals.  For  an  organization  to  get  results,  the  cumu¬ 
lative  impact  of  all  improvement  efforts  should  not  be  overwhelm¬ 
ing  to  anyone.  Later,  as  the  baseline  activities  start  to  produce  find¬ 
ings  and  recommendations,  these  new  activities  will  have  to  be  pri¬ 
oritized  against  and  reconciled  with  the  existing  and  currently 
planned  initiatives. 

Objectives  Identify  all  existing  and/or  anticipated  improvement  efforts  in  this 

organization,  either  internally  or  externally  driven  (such  as  corpo¬ 
rate  initiatives). 

Entry  Criteria  Initiatives  identified  from  a  strategic  business  plan  or  similar  sourc¬ 

es. 


Exit  Criteria  Other  initiatives  identified,  prioritized,  and  preferably  reconciled, 

with  the  result  documented  in  the  SPI  strategic  action  plan. 

Outputs  SPI  strategic  action  plan,  related  initiatives  identified  in  “Improve¬ 

ment  Agenda”  section  (see  Appendix  C.0,  Charters  and  Templates, 
page  175). 

Tasks  •  Identify  all  existing  and/or  anticipated  improvement  efforts  in 

this  organization,  either  internally  or  externally  driven  (such  as 
corporate  initiatives). 


Estimate  resource  investments  in  each  and  resources  required  to 
complete,  including  deploying  the  improvement  throughout  the 
organization. 
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Estimate  the  total  amount  of  resources  that  the  organization  is 
able  and  willing  to  commit  to  these  initiatives. 

Prioritize  the  initiatives  based  on  resource  limitations  and 
detennine  what  areas  the  organization  is  willing  to  apply 
resources  to  and  how  many  resources  it  is  willing  to  apply. 

Document  the  results  in  related  initiatives  identified  in 
“Improvement  Agenda”  section  of  the  SPI  strategic  action  plan 
(see  Appendix  C.0,  Charters  and  Templates,  page  175). 
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3.10  Finalize  Roles  and  Responsibilities  of  the 

Various  Infrastructure  Entities 


Purpose  The  purpose  of  this  activity  is  to  clearly  establish  the  organizational 

methods/design  for  formally  managing  the  SPI  activities.  It  also  es¬ 
tablishes  credibility  with  the  rest  of  the  organization  that  manage¬ 
ment  is  serious  about  this  initiative. 

This  activity  may  repeat  some  of  the  work  done  in  Step  1 .0,  Initiate 
Software  Process  Improvement  (page  7).  Sometimes  this  repetition 
is  not  needed,  but  often,  the  MSG  has  different  members  than  those 
who  set  up  the  SPI  program,  and  they  will  need  to  cover  some  of  the 
same  topics  to  develop  their  own  understanding  and  strategy.  When 
this  step  is  entered  as  a  result  of  a  subsequent  cycle  through  the  im¬ 
provement  roadmap,  these  topics  should  be  reviewed  at  a  minimum. 

Objectives  •  Finalize  roles  and  responsibilities  for  the  SEPG,  MSG,  and  any 

other  SPI  management  and  coordination  groups. 

•  Define  typical  roles  and  responsibilities  for  technical  working 
groups(TWGs)  in  terms  of  their  responsibilities,  authority, 
reporting  requirements,  etc. 

Entry  Criteria  Strategic  planning  activity  launched. 

Inputs  Draft  infrastructure  charters  from  Step  1.8,  Launch  the  Program 

(page  42)  or  past  strategic  plan. 

Exit  Criteria  Roles  and  responsibilities  defined  and  documented  in  the  “Organi¬ 

zation”  section  of  the  SPI  strategic  action  plan. 

Outputs  SPI  strategic  action  plan  “Organization”  section. 

Tasks  •  Define  roles  and  responsibilities  for  the  MSG,  SEPG,  TWGs, 

etc.  (or  extract  from  their  charter). 

•  Document  roles  and  responsibilities  in  the  “Organization” 
section  of  the  SPI  strategic  action  plan. 
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3.11 


Develop  SPI  Project  Selection  Criteria  and 
Process 


Purpose  Publicly  document  an  objective  approach  to  deciding  which  of  the 

many  competing  SPI  recommendations  and  actions  will  be  launched 
and  funded.  This  procedure  will  be  used  whenever  new  ideas  are 
added  to  the  list  of  actions  awaiting  resources. 

Objectives  Define  criteria  for  selection  of  SPI  projects. 


Entry  Criteria  General  purpose  SPI  goals  defined. 

Inputs  Prioritization  criteria  from  review  of  key  business  issues  or  similar 

source. 


Exit  Criteria 


Outputs 

Tasks 


Criteria  for  selection  of  SPI  projects  defined  and  documented  in  the 
SPI  “Project  Selection”  section  of  the  SPI  strategic  action  plan. 

SPI  strategic  action  plan  “Project  Selection”  section. 

•  Define  criteria  to  be  used  to  select  action  items  from  a  list  and 
launch  them. 


•  Define  a  process  to  apply  those  criteria. 

•  Define  a  process  to  add  new  actions  and  to  remove  outdated 
actions  from  the  pending  list. 

•  Document  the  criteria  in  the  “Project  Selection”  section  of  the 
SPI  strategic  action  plan. 
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3.12  Put  Together  SPI  Strategic  Action  Plan  and 

Determine  Baselines  Required 


Purpose  Once  all  the  individual  sections  are  ready,  the  SPI  strategic  action 

plan  is  ready  to  be  put  together.  It  is  at  this  point  that  specific  infor¬ 
mation  needs  will  be  identified  that  cannot  be  answered  by  simple 
review  of  other  sources  of  information  or  by  choosing  among  alter¬ 
natives.  Usually  at  this  point  there  will  be  a  need  to  fonn  special 
teams  to  develop  baselines  of  the  current  state  of  the  organization  in 
one  or  more  dimensions.  The  most  common  form  of  baseline  is  to 
conduct  a  software  process  assessment  (SPA),  described  in  Appen¬ 
dix  D.0,  Establish  Organization  Process  Maturity  Baseline 
(page  193).  Other  forms  of  baselines  include  collecting  metrics  to 
support  the  strategic  goals  identified,  documenting  the  current  pro¬ 
cesses,  and  so  on.  Step  4.0,  Baseline  Current  State  (page  99)  de¬ 
scribes  the  baseline  selection  process  in  more  detail. 

Objectives  •  Put  together  all  sections  completed  to  date  of  the  SPI  strategic 

action  plan. 


•  Identify  infonnation  required  to  define  the  organization’s 
current  state. 

Entry  Criteria  •  Steps  3.1  through  3. 11  completed. 

Inputs  •  General  SPI  goals. 

•  Finalized  charters  and  roles  /responsibilities  defined  for 
different  groups. 

•  Project  selection  criteria  and  process. 

•  Competing/complimentary  initiatives. 

SPI  guiding  principles. 

•  Motivations  to  improve. 

Exit  Criteria  The  first  draft  of  the  plan  is  complete  and  the  baselines  needed  have 

been  identified. 
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Outputs 


Tasks 


•  SPI  strategic  action  plan. 

Resources  and  charters  for  baselining  groups. 

•  Put  together  the  SPI  strategic  action  plan. 

•  Identify  those  areas  needing  further  data  gathering  and  analysis. 
Examples  include  SPAs,  measurement  data  to  support  the  goals, 
current  process  baselines. 

•  Prepare  charters  for  each  baseline  team  and  allocate  resources  to 
that  activity. 
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3.13  Reconcile  the  Existing/Planned  Improvement 

Efforts  with  the  Baseline  Findings  and 
Recommendations 


Purpose  The  baselines,  particularly  the  maturity  baseline,  typically  identify 

issues  and  provide  recommendations  based  on  a  much  broader  con¬ 
sensus  than  may  have  been  available  before.  These  issues  and  rec¬ 
ommendations  serve  to  provide  some  guidance  and  often,  a  prioriti¬ 
zation  of  actions. 


Objectives 


Entry  Criteria 
Inputs 


Exit  Criteria 


Outputs 


Tasks 


The  results  of  the  baselines  should  be  incorporated  into  the  SPI  stra¬ 
tegic  action  plan  and  reconciled  with  all  other  existing  and/or 
planned  improvement  efforts.  This  will  result  in  one  single  strategy 
dealing  with  all  software  process  improvement  actions  and  all  relat¬ 
ed  improvement  efforts  affecting  the  same  groups  of  people. 

•  Incorporate  baseline  results  into  the  SPI  strategic  action  plan. 

•  Reconcile  baseline  results  with  all  other  existing  and/or  planned 
software  improvement  activities. 

•  Baseline  results  ready. 

•  SPI  strategic  action  plan. 

•  Baseline  results  and  recommendations. 

A  single  coherent  strategy  is  defined,  incorporating  baseline  results 
and  other  improvement  efforts. 

•  Composite  action  list. 

•  Matrix  relating  baseline  recommendations  and  issues  to  other 
existing/planned  activities. 

•  Reconciled  plan. 

•  Review  the  results  of  the  baseline  efforts. 
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mendations 


•  Build  a  matrix  relating  recommendations  from  the  baselines  to 
existing  and  planned  activities. 

Review/revise  goals  as  appropriate. 
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3.14  Transform  the  General  SPI  Goals  to  Specific 

Measurable  Goals 


Purpose  Now  that  the  results  of  the  baseline  activities  have  been  reconciled, 

sufficient  data  should  be  available  to  take  the  general  long-term  and 
short-term  goals  developed  in  Step  3.6,  Define  General  SPI  Goals 
(page  84),  and  make  them  specific.  This  is  done  by  incorporating  the 
measurement  of  the  current  state  of  those  goals  and  defining  an  ag¬ 
gressive  but  achievable  improvement  in  those  measures. 

For  example,  one  general  goal  could  have  been  to  make  software 
projects  more  predictable  in  tenns  of  cost  and  schedule.  The  mea¬ 
surement  baseline  established  that  80  percent  of  current  projects  ex¬ 
ceed  their  original  (bid)  cost  and  schedule  estimates  by  more  than  25 
percent.  The  revised  goal  could  be  to  improve  that  measure  such  that 
80  percent  of  all  projects  complete  within  10  percent  of  their  original 
estimates,  (adjusted  for  changes  of  scope  along  the  way)  within  2 
years. 


The  above  is  an  example  of  how  to  transform  a  general  business  goal 
into  a  specific  measurable  process  improvement  goal. 

Objectives 

Transform  all  general  goals  into  specific,  measurable  goals. 

Entry  Criteria 

Measurement  baseline  complete 

Inputs 

•  Measurement  baseline  results  and  recommendations. 

•  SPI  strategic  action  plan  (“General  Goals”  section). 

Exit  Criteria 

Goals  finalized 

Outputs 

Measurable  goals 

Tasks 

•  Transform  the  goals  into  measurable  specific  improvement 
goals. 
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3.15 


Update  the  SPI  Strategic  Action  Plan 


Purpose 

Objectives 
Entry  Criteria 
Exit  Criteria 
Outputs 
Tasks 


Now  that  all  sections  of  the  SPI  strategic  action  plan  are  ready,  the 
plan  has  been  reconciled  with  the  baseline  results,  and  the  goals 
transformed,  the  plan  has  to  be  put  together,  edited,  and  finalized. 

Finalize  the  SPI  strategic  action  plan. 

All  sections  completed  or  inputs  finalized. 

Complete  SPI  strategic  action  plan  written. 

Updated  SPI  strategic  action  plan. 

Merge  the  various  sections  developed  during  previous  steps  in 
this  process. 


Edit,  resolving  inconsistencies,  etc. 
•  Prepare  final  draft  for  review. 
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3.16  Build  Consensus,  Review,  and  Approve  the  SPI 

Strategic  Action  Plan  and  Commit  Resources  to 
Action 


Purpose 


Objectives 


A  strategic  plan  is  no  good  if  it  is  built  in  a  vacuum  and  only  a  small 
group  believes  in  it.  To  be  useful,  it  has  to  be  “sold,”  and  consensus 
has  to  be  developed. 

•  Approve  SPI  strategic  action  plan. 


•  Build  consensus  and  commitment  to  the  plan. 
Entry  Criteria  Complete  draft  plan  ready. 

Exit  Criteria  Plan  finalized  and  signed  off. 


Outputs 

Tasks 


Final,  approved  SPI  strategic  action  plan. 

•  Present/review  the  plan  at  all  levels  of  the  organization. 

•  Collect  comments  and  suggestions  and  resolve  conflicting  ideas. 

•  Incorporate  all  changes  and  have  all  senior  line  managers  as  well 
as  the  organization’s  senior  manager  sign  the  plan. 

•  Publicize  the  plan  (send  a  copy  to  everyone  in  the  organization). 
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4.0  Baseline  Current  State 


Purpose  The  baselines  will  describe  how  and  how  well  the  organization  cur¬ 

rently  performs  its  software  business.  The  knowledge  of  the 
strengths  and  opportunities  for  improvement  is  an  essential  prereq¬ 
uisite  for  identifying  and  prioritizing  an  effective  and  efficient  SP1 
program. 


The  management  steering  group  (MSG)  must  understand  the  orga¬ 
nization’s  present  state  to  develop  a  plan  that  will  achieve  the  busi¬ 
ness  changes  specified  in  the  organization  strategic  plan  for  SP1  and 
the  SP1  strategic  action  plan.  The  baseline  activities  input  this  infor¬ 
mation  into  the  SP1  planning  and  prioritization  process. 

A  recommended  minimum  set  of  baselines  includes 

•  Organization  process  maturity  baseline  (software  process  ap¬ 
praisal  or  assessment).  See  Appendix  D.0,  Establish  Organiza¬ 
tion  Process  Maturity  Baseline  (page  193). 

•  Process  description  baseline  (initial  software  process  map). 

•  Metrics  baseline  (initial  level  of  business  and  process  metrics  to 
measure  progress  against). 

For  each  baseline  many  effective  methods  of  gathering  infonnation 
are  available.  For  the  process  maturity  baseline,  a  third-party  con¬ 
tractor  can  do  an  evaluation  with  the  capability  maturity  model 
(CMM)  or  their  own  proprietary  maturity  ratings,  or  the  organiza¬ 
tion’s  own  personnel  can  be  trained  to  assess  their  process  maturity. 
The  MSG  must  choose  the  number  and  type  of  baselines  that  best 
achieve  the  objectives  it  has  set  and  then  create  a  baseline  action 
plan  for  each. 

Information  about  the  current  state  of  the  organization  flows  to  the 
MSG  by  means  of  the  baseline  findings  and  recommendations  re¬ 
ports.  Because  the  baseline  reports  will  not  necessarily  coincide  in 
time,  infonnation  will  flow  irregularly.  As  infonnation  is  available, 
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Objectives 


the  MSG  incorporates  it  into  the  improvement  plans.  Baselines  do 
not  detennine  the  strategy,  however.  The  strategy  for  improvement 
must  be  based  on  business  goals  and  needs.  The  baselines  can  help 
determine  the  current  state  of  the  organization  with  respect  to 
achieving  those  goals  or  being  capable  of  achieving  them. 

Infonnation  on  the  current  state  will  also  be  used  by  the  technical 
working  groups  (TWGs)  during  Step  5.0,  Develop  Improvements 
(page  103)  to  develop  process  improvement  solutions.  Keeping  the 
momentum  of  process  improvement  between  baselining  and  deploy¬ 
ment  is  very  important. 

Baselines  are  intended  to  be  iterative;  the  major  baselines  conducted 
at  this  point  provide  a  snapshot  of  the  organization’s  various  capa¬ 
bilities,  processes,  and  measures.  Subsequent  cycles  through  the 
strategic  portion  of  the  roadmap  will  require  repeated  baselining  to 
show  what  progress  or  changes  have  taken  hold  in  the  organization. 
Software  maturity  baselines  should  be  repeated  every  eighteen 
months  to  three  years.  Metrics  baselines  should  probably  be  taken 
more  often,  depending  on  the  business  cycle  of  the  organization  (if 
the  organization  goes  through  a  full  cycle  only  every  two  years, 
more  frequent  metrics  baselines  would  probably  not  be  useful.  On 
the  other  hand,  if  the  organization  goes  through  a  product  cycle  ev¬ 
ery  three  months,  metrics  baselines  could  be  taken  annually.) 

Determining  what  to  baseline  and  how  to  baseline  is  a  decision  that 
very  much  depends  on  the  organization.  Many  software  organiza¬ 
tions  will  have  certain  types  of  baselines  detennined  for  them  by 
what  business  they  are  in,  such  as  Software  Engineering  Institute 
(SEI)  software  capability  evaluations  (SCEs)  for  government  con¬ 
tracts,  ISO  9000  certifications,  Malcolm  Baldridge  evaluations,  or 
internal  company  audits.  Even  in  the  face  of  “external”  baselines,  an 
organization  should  create  its  own  baseline  activities  that  can  be 
properly  tuned  to  meet  the  business  and  infonnation  goals  of  the  or¬ 
ganization. 

•  Understand  the  working  of  the  current  processes  and  the  organi¬ 
zational  interactions  and  how  they  contribute  to  the  organiza¬ 
tion’s  business. 
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Education/Training 

Communication 

Entry  Criteria 

Verification 

Exit  Criteria 

Tasks 


•  Gather  information  on  the  current  strengths  and  opportunities  for 
improvement  in  the  organization  for  input  to  the  SPI  planning 
process. 

•  Build  involvement  from  the  senior  management  team  down  to 
the  staff  for  process  improvement  tasks  that  will  make  the  work 
of  the  organization  more  effective. 

•  Detail  the  starting  point  for  measuring  improvement. 

The  SEPG  and  TWGs  should  have  training  in 

•  Change  management. 

•  Team  facilitation. 

•  Specific  baselining  methods  [for  example,  SEI  software  process 
assessment  (SPA),  process  modeling,  interviewing]. 

Each  of  the  baselining  activities  will  have  specific  communication 
needs.  In  addition,  getting  the  organization  ready  for  baselining  will 
require  considerable  communication,  establishing  dialogue  between 
various  levels  and  areas  in  the  organization  to  maximize  the  effec¬ 
tiveness  of  the  baselining  teams. 

•  SPI  infrastructure  must  exist. 

•  SPI  implementation  plan  must  exist. 

•  Organization  strategic  plan  for  SPI  started. 

The  baselining  activities  must  be  self-verifying.  The  credibility  of 
the  baselines  depends  on  their  perceived  ability  to  extract  real, 
meaningful  infonnation  from  the  organization  and  present  it  back  to 
the  organization  in  a  coherent,  actionable  form. 

•  Baseline  Findings  and  Recommendation  Reports  delivered  to 
the  MSG. 

•  Detennine  the  baseline  infonnation  that  is  required  and  a  strate¬ 
gy  for  collecting  the  information  (complete  part  of  the  SPI  im¬ 
plementation  plan). 

Establish  TWGs  with  charters  (baseline  action  plans),  schedules, 
and  resources  for  each  desired  baseline. 

•  Perform  various  baseline  assessments. 


CMU/SEI-95-UG-001 


101 


4.0 


Baseline  Current  State 


•  Track  TWG  progress  and  redirect  as  necessary. 

•  Incorporate  baseline  reports  (baseline  findings  and  recommen¬ 
dations  report)  and  recommendations  into  SPI  plans  (SPI  strate¬ 
gic  action  and  tactical  action  plans)  during  Step  3.0,  Build  Soft¬ 
ware  Process  Improvement  Strategy  (page  69). 
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5.0  Develop  Improvements 


Overview  This  step  is  the  process  in  which  technical  working  groups  (TWGs) 

develop  specific  improvements  to  specific  processes.  There  are  two 
basic  approaches  to  designing  solutions: 


1 .  Focus  on  solving  specific  problems. 

2.  Incrementally  improve  a  particular  process. 

In  the  first  approach,  the  TWGs  focus  on  a  specific  problem  and  de¬ 
velop  a  solution  using  pilot  projects  to  validate  and  refine  the  solu¬ 
tion.  In  the  second  approach,  the  TWGs  focus  on  a  particular  process 
and  develop  incremental  refinements  to  it,  again  using  pilot  projects 
to  test  out  the  refinements.  There  will  probably  be  several  of  these 
process  improvement  projects  running  simultaneously.  This  process 
represents  the  typical  TWG  life  cycle  for  producing  process  im¬ 
provements,  and  so  is  written  from  this  point  of  view.  The  steps  and 
processes  for  the  software  engineering  process  group  (SEPG)  and 
management  steering  group  (MSG)  are  described  primarily  in  Step 
2.0,  Manage  the  Software  Process  Improvement  Program  (page  43), 
which  runs  in  parallel  with  this  step. 

Purpose  The  purpose  of  this  phase  is  to  develop  improvements  and  solutions 

to  the  process  issues  found  during  the  baselining  phase.  The  key  pro¬ 
cesses  and/or  problems  have  been  prioritized  and  selected  during  the 
previous  phases;  the  process  described  in  this  step  is  where  the  actu¬ 
al  work  of  providing  refinements  to  the  key  processes  or  fixing  those 
problems  is  performed.  The  results  of  this  work  will  be  turned  over 
to  the  SEPG  and  MSG  to  include  in  the  overall  process  improvement 
architecture  and  to  project  development  teams  to  finally  incorporate 
into  their  project  execution. 
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Objectives 


Education 


Commitment 


The  TWG  will 

•  Plan  the  project. 

Understand  the  process,  including  customers  needs,  and  develop 
refinements  to  it  (process  orientation). 

•  Investigate  the  problem  and  develop  a  solution  (problem  orien¬ 
tation). 

•  Pilot  a  solution  and  validate  and  refine  it. 

•  Develop  rollout  strategy  and  plan  template  for  applying  the  so¬ 
lution. 

Evaluate  the  project. 

•  Re-iterate  the  cycle  for  further  improvements. 

TWGs  have  communication  needs  similar  to  the  assessment  team 
and  the  SEPG  when  they  start  up.  Specific  TWG  training  needs  are 

Change  management,  focusing  on  target  readiness  [suggested 
source:  “Managing  Technological  Change”  taught  by  the 
Software  Engineering  Institute  (SEI)]. 

Team  development,  focusing  on  building  cohesive,  successful 
implementation  teams  (suggested  source:  Scholtes,  Peter  R.  The 
TEAM  Handbook:  How  to  Use  Teams  to  Improve  Quality.  Mad¬ 
ison,  WI:  Joiner,  1988;  and  associated  classes  from  Joiner  Asso¬ 
ciates). 

Process  improvement,  (suggested  source:  TEAM  Handbook  and 
associated  classes  from  Joiner  Associates). 

Since  the  TWG  receives  its  charter  from  the  MSG,  overall  commit¬ 
ment  to  the  TWG  charter  is  assumed.  However,  additional  sponsor¬ 
ship  and  deeper  commitment  for  the  specific  changes,  staffing,  and 
commitments  of  pilot  projects,  and  building  the  capability  of  the  or¬ 
ganization  to  receive  the  TWG  products,  is  needed.  Commitment 
should  come  from  several  distinct  groups: 
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Communication 


Entry  Criteria 


•  Senior  management:  The  TWG  must  periodically  refresh 
the  commitment  of  the  MSG  through  progress  reports, 
clarification  on  issues  and  goals,  and  involvement  in 
organization-wide  decisions. 

•  Middle  management:  The  TWGs  must  gain  commitment 
from  middle  managers  for  their  own  time  and  the  time  required 
from  pilot  projects  to  develop  solutions. 

Line  management  and  practitioners:  The  TWGs  will  need 
to  establish  the  commitment  and  consensus  of  those  who  will  be 
implementing  the  process  improvement  as  part  of  their  product 
development  projects.  This  requires  getting  early  feedback  and 
continuing  to  elicit  input  and  gain  agreement  from  the  various 
projects  on  the  content  of  the  process  improvement  as  well  as 
how  it  is  to  be  initiated  and  supported. 

The  TWGs  have  to  communicate  with  those  who  support  them.  In 
addition,  the  TWG  will  be  working  with  solution  providers  to  get  the 
best  solution  in  the  organization. 

Specific  communications: 

TWG  to  SEPG:  primarily  status  updates  and  requests  for 
information  and  assistance. 

TWG  to  MSG:  primarily  status  updates  and  requests  for  re- 
source-level  approvals;  occasionally  requests  for  arbitration/de¬ 
cisions  affecting  the  organization  that  the  TWG  or  the  SEPG 
cannot  make. 

TWG  to  target  groups:  The  TWG  must  elicit  requirements 
and  feedback  from  the  eventual  target  groups  to  ensure  that  the 
needs  of  these  groups  are  met  by  the  eventual  solution.  In  addi¬ 
tion,  the  TWG  should  solicit  interest  in  pilot  participation  from 
the  affected  target  groups. 

TWG  to  pilots:  For  the  TWG  to  get  the  appropriate  feedback  to 
refine  the  process  improvement  solution,  significant  communi¬ 
cation  is  required  to  ensure  the  proper  execution  of  the  pilot 
project. 

•  TWG  charter  and  tactical  action  plan  template  from 
MSG/SEPG. 
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Exit  Criteria 


Tasks 


•  Process  maturity  issues  from  baselining  step. 

•  Related  recommendations  and  “low-hanging  fruit”  (quick-fix, 
quick-retum  improvement  projects)  from  baselining  step. 

High-level  process  descriptions  from  process  baselining  step. 

•  Key  process  metrics  from  metrics  baselining  step. 

Completed  pilots. 

Installation  plan  developed. 

Solution  turned  over  to  SEPG. 

See  Figure  5-1:  Activities  in  Step  5.0,  Develop  Improvements  on 
page  107  for  a  pictorial  representation  of  the  tasks. 
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Figure  5-1:  Activities  in  Step  5.0,  Develop  Improvements 
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The  subtasks  for  5.0,  Develop  Improvements,  are 


Subtask 

Page 

Number 

5.1:  Form  the  Technical  Working  Group  (TWG) 

109 

5.2:  Plan  the  Project 

111 

5.3:  Refine  the  Process  (Process-Centered  Approach) 

112 

5.4:  Analyze  and  Fix  the  Problem  (Problem-Centered  Approach) 

113 

5.5:  Pilot  Solutions 

114 

5.6:  Select  Solution  Providers 

115 

5.7:  Determine  Long-Term  Support  Needs 

117 

5.8:  Develop  Rollout  Strategy  and  Plan  Template 

118 

5.9:  Package  the  Improvement  and  Turn  Over  to  the  SEPG 

120 

5.10:  Disband  Technical  Working  Group  (TWG) 

122 
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5.1  Form  the  Technical  Working  Group  (TWG) 


Purpose  For  improvements  that  take  more  than  a  couple  of  days  of  one  per¬ 

son’s  time  and  affect  several  people,  a  team  approach  usually  works 
best.  The  team  should  be  composed  of  volunteers  from  the  target  au¬ 
dience  (those  who  will  ultimately  adopt  the  process  improvement) 
who  are  enthusiastic  about  working  on  the  improvement.  This  group 
of  people  can  be  identified  during  the  baselining  portion  of  the  road¬ 
map.  In  the  recommendation-generating  step  of  the  maturity  base¬ 
line,  people  can  be  asked  to  rank  the  alternatives  by  their  own  enthu¬ 
siasm.  When  a  particular  solution  area  is  decided  upon,  these  people 
can  be  contacted  to  commit  to  the  project  “for  real.” 

Objectives  Build  a  team  from  people  with  diverse  backgrounds  who  all  have  a 

stake  in  the  area  of  improvement. 

Entry  Criteria  •  TWG  charter  and  draft  tactical  action  plan  from 

MSG/SEPG. 

High-level  process  descriptions  from  process  baselining  step. 

•  Process  maturity  issues  from  maturity  baselining  step. 

•  Related  recommendations  and  “low-hanging  fruit”  from  maturi¬ 
ty  baselining  step. 

•  Key  process  metrics  from  metrics  baselining  step. 

Exit  Criteria  •  Team  established. 

Tasks  •  Assign  MSG  sponsor  responsibility  to  one  MSG  member.  The 

TWG  needs  one  person  on  the  MSG  to  act  as  primary  sponsor 
and  advocate.  This  person  is  usually  the  process  owner  of  the 
particular  area  the  TWG  is  going  to  be  improving.  The  MSG 
sponsor  will  have  the  responsibility  to  communicate  issues  about 
the  TWG  to  other  MSG  members  and  to  give  feedback  to  the 
TWG  from  the  MSG. 

•  Assign  SEPG  liaison  responsibility  to  one  SEPG  member.  The 
SEPG  liaison 
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Acts  as  facilitator  or  “quality  advisor”  (see  Scholtes, 
Peter  R.,  The  TEAM  Handbook:  How  to  Use  Teams  to 
Improve  Quality )  to  the  TWG. 

Brings  the  data  from  the  baselining  steps  to  the  other 
TWG  members. 

Facilitates  the  flow  of  infonnation  between  the  various 
people  and  groups  involved  in  process  improvement, 
such  as  between  the  TWG  and  the  MSG  and  other 
organizations,  and  among  the  team  members  themselves. 

Acts  as  the  surrogate  leader,  when  the  TWG  is  beginning 
its  work,  until  the  designated  or  agreed  upon  TWG  leader 
can  take  over. 

Get  the  enthusiastic  people  from  the  organization  to  work  on  the 
team.  During  the  recommendations  step,  people  prioritize  im¬ 
provements  based  on  their  enthusiasm  for  the  improvement  area. 
No  commitment  is  implied  at  that  time,  however.  Now  that  the 
improvement  areas  have  been  identified,  the  same  people  should 
be  contacted  to  see  if  they  are  still  interested.  Their  commitment 
and  the  commitment  of  their  managers  must  be  secured  for  them 
to  work  on  the  team. 

Plan  and  conduct  a  team  kickoff  meeting  with  sponsor  attending. 
The  first  team  meeting  should  be  conducted  with  all  TWG  mem¬ 
bers,  the  SEPG  liaison,  and  the  MSG  sponsor  present  to  official¬ 
ly  start  up  the  TWG.  Materials  should  have  been  exchanged  be¬ 
fore  this  time,  but  this  is  the  official  hand-off  of  the  draft  charter 
and  tactical  action  plan  from  the  MSG  to  the  TWG.  For  other  ac¬ 
tivities  that  should  go  on  during  the  first  meeting,  refer  to  The 
TEAM  Handbook. 

Set  up  initial  schedule  for  TWG.  The  TWG  should  set  up  an  ini¬ 
tial  schedule  of  working  meetings  to  get  through  the  next  two  or 
three  steps. 
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5.2  Plan  the  Project 


Purpose  Produce  a  draft  tactical  action  plan  that  is  reviewed  with  the  MSG. 

The  team’s  early  efforts  must  be  focused  on  narrowing  the  scope  of 

the  charter  to  the  specific  improvement  on  which  they  will  work. 

Objectives  •  Complete  the  tactical  action  plan  sections  not  specified  by  the 

MSG,  and  fill  in  other  areas  of  the  plan. 

•  Narrow  the  scope  of  the  project  to  something  that  can  be  done  in 
a  finite  amount  of  time. 

Entry  Criteria  Tactical  action  plan  draft  from  MSG. 

Exit  Criteria  Tactical  action  plan  approved  by  MSG. 

Tasks  •  Review  draft  tactical  action  plan  with  MSG  sponsor  and  SEPG 

liaison. 

•  Review  data  from  baselining  phase  with  SEPG  liaison. 

•  Develop  task  sorting  and  selection  criteria. 

•  Explore  problem  area  to  get  preliminary  directions  for  the  team. 
Create  work  breakdown  structure  (WBS)  for  TWG. 

•  Organize  WBS  tasks  into  a  schedule  with  milestones  and  deliv¬ 
erables. 

•  Review  and  refine  with  MSG  sponsor  and  SEPG  liaison. 
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5.3  Refine  the  Process  (Process-Centered 

Approach) 


Purpose  The  process-centered  approach  deals  with  understanding  a  specific 

key  process  identified  during  the  baselining  phase  and  applying  in¬ 
cremental  refinements  to  the  process.  This  approach  is  useful  for 
achieving  long-term  improvements  in  the  process.  However,  be¬ 
cause  of  the  immediate  pressures  and  uncertainties  typical  of  lower 
level  maturity  organizations,  it  is  difficult  to  maintain  this  focus  in 
such  organizations.  Sustaining  a  process-centered  approach  requires 
strong  management  commitment  and  organization-al  momentum 
and  enthusiasm.  The  problem-centered  approach  is  recommended 
for  first-time  process  improvement  programs. 

Objectives  •  Understand  the  process. 

•  Eliminate  errors,  reduce  variations. 

Set  up  a  continuous  improvement  cycle  for  the  process. 

•  Process  baseline  and  maturity  issue  data  from  the  baselining 
phase. 

•  Tactical  action  plan. 

Solution  components  identified:  process  descriptions,  procedures, 
metrics,  methods,  and  tools 

•  Identify  process  stakeholders  and  understand  their  needs. 
Determine  process  scope  /  boundaries  /  context. 

Describe  the  desired  state  of  the  process  (the  “ideal”). 

•  Determine  process  modeling  objectives. 

Model  the  new  process. 

Specify  process  metrics. 

•  Implement  the  process. 


Entry  Criteria 


Exit  Criteria 

Tasks 
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5.4  Analyze  and  Fix  the  Problem  (Problem-Centered 

Approach) 


Purpose  The  problem-centered  approach  is  distinct  from  the  process-cen¬ 

tered  approach  in  that  it  is  more  useful  for  easily  identifiable  prob¬ 
lems  and  can  provide  results  faster  than  the  process-centered  ap¬ 
proach.  When  problems  become  complex  or  solutions  unwieldy, 
however,  the  results  of  the  problem-centered  approach  are  often 
overtaken  by  other  problems  that  crop  up  when  early  problems  are 
fixed.  Because  it  will  get  the  momentum  up  and  keep  enthusiasm 
alive,  the  problem-centered  approach  is  useful  for  getting  a  SPI  pro¬ 
gram  started.  However  the  process-centered  approach  will  be  more 
useful  for  long-tenn  results. 

Objectives  Develop  solutions  to  specific  problems. 

Entry  Criteria  •  Problem  and  issue  data  from  the  baselining  phase. 

•  Tactical  action  plan. 

Exit  Criteria  Solution  components  identified:  process  descriptions,  procedures, 

metrics,  methods,  and  tools. 

Tasks  •  State  the  problem. 

•  Define  solution  goals  and  criteria. 

•  Identify  constraints. 

•  Analyze  the  problem  to  detennine  root  causes. 

•  Generate  and  select  alternatives  to  address  root  causes. 

•  Define  solution  metrics. 

•  Implement  solution. 
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5.5  Pilot  Solutions 


Purpose  Pilot  projects  are  used  to  test  out  the  solutions  in  both  the  process- 

centered  and  problem-centered  approaches.  The  solutions  will  re¬ 
quire  some  tailoring  and  refinement  to  fit  them  into  projects  across 
the  organization,  and  the  pilots  will  help  detennine  the  tailoring 
needs  and  guidelines  for  the  rest  of  the  organization.  Several  pilots 
may  be  run  for  a  solution,  and  there  may  be  several  iterations  be¬ 
tween  the  solution  development  and  piloting  steps  to  get  the  solution 
ready  for  deployment  across  the  organization. 

Objectives  •  Verify  the  solution  in  a  real  project  in  the  organization. 

Capture  learnings  and  results  of  pilot  to  refine  the  solution  and 
the  installation  of  the  solution. 

Solution  components:  process  description,  procedures,  metrics, 
methods,  and  tools. 

Training  and  installation  needs  identified  and  planned  for. 

Pilot  project  completion  criteria  are  met. 

Learnings  and  results  of  pilot  captured  and  preserved  by  TWG. 

Develop  pilot  selection  and  completion  criteria. 

Identify  potential  pilot  projects. 

Select  pilot  project  team. 

Train  pilot  project  team. 

Install  solution  in  pilot  project. 

Execute  and  monitor  pilot  project. 

Evaluate  results  of  pilot. 


Entry  Criteria 


Exit  Criteria 


Tasks 
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5.6  Select  Solution  Providers 


Purpose  There  may  be  several  sources  of  support  for  the  process  improve¬ 

ment  solution,  some  competing,  others  complementary.  Given  the 
organization’s  varying  needs,  the  TWG  must  determine  the  best 
source  for  support.  During  this  phase  the  TWG  should  work  closely 
with  the  SEPG  to  use  established  and  vetted  solution  providers. 

This  step  runs  in  parallel  with  the  solution  creation  steps.  The  solu¬ 
tion  provider(s)  may  be  part  of  detennining  the  solution,  and  in  some 
cases  the  selection  criteria  for  providers  may  not  be  determined  until 
well  into  pilot  testing  the  solution.  Especially  when  several  tools 
may  be  competing,  the  TWG  must  establish  working  relationships 
with  various  vendors  to  get  the  best  solution  for  the  organization. 

Objectives  Investigate  various  providers  of  solutions  and  their  solutions  to  find 

ones  that  best  match  the  needs  of  the  organization,  both  short-  and 
long-term. 

Entry  Criteria  TWG  has  developed  a  set  of  solutions  for  the  process  issue  at  hand. 

Inputs  •  Problem  descriptions  and  analyses. 

•  Description  of  solutions. 

Exit  Criteria  Designated  solution  provider(s)  for  the  solution  are  ready  to  imple¬ 

ment  and  provide  support. 

Outputs  Contract  with  solution  provider(s). 

Tasks  •  Obtain  contacts  for  providers  of  solutions  (from  SEPG). 

•  Contact  providers  and  arrange  briefing  sessions. 

•  Develop  selection  criteria  based  on  organization  needs  and  range 
of  possibilities  among  providers. 

•  Narrow  down  the  set  of  providers  to  one  or  two  that  best  meet 
needs  and  are  ready  to  work  with  the  organization. 
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•  Develop  contracts  with  solution  providers. 
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5.7  Determine  Long-Term  Support  Needs 


Purpose  Long-term  solutions  will  require  long-term  support.  As  the  solution 

is  implemented  in  other  parts  of  the  organization,  new  people  will 
have  to  be  trained,  new  problems  may  crop  up,  and  additional  tailor¬ 
ing  may  be  needed.  This  step  identifies  the  requirements  for  long¬ 
term  support  in  terms  of  knowledge  and  skills  required,  how  defects 
are  fixed,  installation  and  configuration  consulting,  etc.  The  im¬ 
provement  should  be  planned  to  last  for  a  few  years  (possibly  as  part 
of  some  larger  improvement  effort).  Ongoing  support  for  any  tools, 
methods,  classes,  materials,  etc.,  should  be  planned  during  the  de¬ 
velopment  step. 

Objectives  •  Identify  long-term  support  needs  and  potential  sources  for  sup¬ 

port. 

•  Plan  internal  long-tenn  support  mechanisms. 

Secure  funding  for  long-tenn  support. 

Entry  Criteria  •  List  of  recommended  solution  providers  from  SEPG. 

Exit  Criteria  •  Specific  solution  provider(s)  chosen. 

Support  contracts  drafted. 

Tasks  •  Work  with  solution  providers  to  satisfy  needs  of  TWG  and  pilot 

solution. 

•  Refine  TWG  and  pilot  needs  to  enable  best  possible  solution  for 
entire  organization. 
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5.8  Develop  Rollout  Strategy  and  Plan  Template 


Purpose  Once  the  solution  has  been  designed  and  the  short-  and  long-tenn 

support  needs  addressed,  the  solution  will  be  ready  to  install  in  the 
organization.  The  TWG  must  create  a  plan  that  gives  guidance  to  the 
development  projects  that  will  be  installing  the  process  improve¬ 
ment: 

•  What  training  they  need. 

•  What  tools  and  methods  to  acquire. 

•  Installation  steps. 

How  to  get  support,  etc. 

This  plan  will  be  used  as  a  template  by  the  project  to  integrate  with 
their  own  project  plans  and  by  the  MSG  to  integrate  the  improve¬ 
ment  into  the  overall  organization  strategic  plan  for  SPI  and  process 
architecture. 

Create  installation  plan  template  for  the  solution,  to  be  customized 
by  other  projects  during  Step  6.0,  Deploy  Improvements  (page  125). 

•  Successful  pilot  implementation. 

•  Generic  installation  plan  template. 

•  Guide  for  developing  installation  plan  template. 

Guide  for  developing/integrating  installation  plans. 

Installation  plan  template  reviewed  and  approved  by  MSG,  SEPG, 
and  pilots. 

Installation  plan  template. 

•  Using  generic  templates,  create  the  installation  plan  for  this  par¬ 
ticular  solution. 

•  Review  template  with  MSG/SEPG  for  approval. 


Objectives 

Entry  Criteria 
Inputs 

Exit  Criteria 

Outputs 

Tasks 
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5.8  Develop  Rollout  Strategy  and  Plan  Template 


•  Integrate  into  process  architecture  of  the  organization. 
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5.9  Package  the  Improvement  and  T urn  Over  to  the  SEPG 


5.9  Package  the  Improvement  and  Turn  Over  to  the 

SEPG 

Purpose  The  TWG  has  developed  several  products  and  artifacts.  These  must 

be  collected  into  a  package  that  can  be  turned  over  to  the  SEPG  for 
long-term  maintenance  and  support.  (This  task  will  be  much  simpler 
if  the  TWG  is  doing  this  as  it  goes  along.) 

Objectives  •  Collect  and  clean  up  all  products  and  artifacts. 

•  Package  products  and  artifacts  for  archival  with  the  SEPG. 

Entry  Criteria  •  Process  improvement s)  are  ready  for  distribution. 

Long-tenn  support  contracts  are  signed  and  solution  providers 
are  ready  to  implement  solutions  throughout  the  organization. 

•  Training  and  support  is  available  for  the  organization. 

Inputs  •  TWG  products  and  artifacts  (minutes,  notes,  plans,  templates, 

diagrams,  charts,  etc.). 

Exit  Criteria  •  All  necessary  artifacts  are  collected  in  a  single  place  for  long¬ 

term  support. 

SEPG  accepts  the  package. 

Outputs  •  Bound  (put  in  a  notebook)  and  cataloged  set  of  products  and  ar¬ 

tifacts. 

Tasks  •  Identify  various  products  and  artifacts  the  team  has  produced. 

•  Collect  clean  copies  of  each  product  and/or  artifact. 

•  Write  descriptive  material  for  those  products  and  artifacts  for 
which  it  is  needed. 

•  Organize  and  catalog  all  the  artifacts. 

Bind  the  products  and  artifacts  into  one  package. 

•  Review  package  content  with  the  SEPG. 
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5.9  Package  the  Improvement  and  Turn  Over  to  the  SEPG 


Archive  the  package  with  the  SEPG,  adding  to  its  database  of 
process  improvement  information  and  beginning  the  mainte¬ 
nance  process  on  the  package. 

Detennine  if  more  improvements  should  be  made  to  this  pro¬ 
cess.  If  so,  then  go  back  to  5.2:  Plan  the  Project.  Otherwise,  go 
on  to  5.10:  Disband  Technical  Working  Group  (TWG).  (See 
Figure  5-1  on  page  107,  the  “more  improvements?”  decision.) 
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5.10  Disband  Technical  Working  Group  (TWG) 


5.10 

Disband  Technical  Working  Group  (TWG) 

Purpose 

The  TWG  has  completed  its  tasks.  As  a  final  task,  the  TWG  should 
also  do  a  final  retrospective  report  that  will  go  to  the  SEPG  and  MSG 
to  help  improve  the  process  for  running  and  managing  TWGs  during 
solution  development.  Finally,  the  team  should  celebrate  what  it  has 
accomplished. 

Objectives 

•  Gather  lessons  learned  from  this  effort. 

•  Celebrate  the  accomplishments  of  this  team. 

Entry  Criteria 

All  improvements  packaged  and  accepted  by  the  SEPG  for  long¬ 
term  support. 

Inputs 

TWG  reports  and  working  records. 

•  Packaged  improvements. 

Exit  Criteria 

Retrospective  report  delivered  to  SEPG. 

•  All  team  members’  efforts  recognized  and  rewarded. 

Outputs 

Retrospective  report. 

Tasks 

•  Review  the  improvement  project.  Gather  lessons  from  the  TWG 
to  improve  the  process  of  improving  processes. 

•  Celebrate  the  completion  of  the  tasks. 

•  Dissolve  the  team. 
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6.0  Deploy  Improvements 


Overview  This  process  puts  an  improvement  into  practice  and  spreads  it  across 

the  organization.  The  various  improvements  that  the  working  groups 
have  been  developing  are  complete  and  their  value  has  been  “prov¬ 
en”  to  the  organization.  The  management  steering  group  (MSG)  and 
the  software  engineering  process  group  (SEPG)  will  be  managing 
and  supporting  the  deployment  of  the  improvements;  their  tasks  are 
mostly  in  Step  2.0,  Manage  the  Software  Process  Improvement  Pro¬ 
gram  (page  43),  which  runs  parallel  to  this  step. 


This  process  links  the  mission  of  the  SPI  program  to  improve  pro¬ 
cesses  and  the  mission  of  the  development  organization  to  produce 
products.  It  is  the  culmination  of  the  SPI  efforts  to  this  point. 

As  with  Step  5.0,  Develop  Improvements  (page  103),  there  may  be 
more  than  one  of  these  steps  occurring  in  parallel.  Unlike  Develop 
Improvements,  however,  the  multiple  instances  will  be  product-line 
organizations  integrating  several  improvements  or  implementing 
one  improvement  at  a  time  in  serial  fashion,  depending  on  the  rollout 
strategy  and  plan  and  the  project  circumstances.  The  multiplicity  of 
improvement  projects  is  handled  in  Step  2.0,  Manage  the  Software 
Process  Improvement  Program  (page  43). 

This  process  entails  the  active  adoption  of  specific  improvements. 
There  must  also  be  a  more  passive,  steady-state  adoption  of  im¬ 
provements,  which  should  be  embodied  in  the  organization’s  pro¬ 
cess  architecture.  The  line  organizations  should  always  design 
their  project  plans  with  the  organization’s  process  architecture  in 
mind.  They  should  apply  variations  only  when  data  tells  them  they 
must  or  when  they  are  deliberately  adopting  a  new  or  modified  pro- 
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Purpose 


Objectives 


Education 


Commitment 


Communication 


Entry  Criteria 


cess  by  the  method  described  below.  We  do  not  discuss  this  more 
passive  adoption  of  process  in  this  document. 

The  purpose  of  this  step  is  to  install  and  institutionalize  the  process 
improvements  coming  from  the  working  groups  into  the  organiza¬ 
tion  as  a  whole. 

•  Bring  line  organizations  “up-to-speed”  on  the  improvement(s) 
they  will  be  using. 

•  Integrate  the  process  improvements  with  new  or  existing  proj  ect 
development  plans. 

•  Monitor  and  support  the  line  organizations  as  they  use  the  new 
or  modified  processes. 

The  development  teams  will  require  some  training  in 
The  new  or  modified  process. 

Associated  methods  and  tools. 

•  Some  of  the  aspects  of  change  management  relating  to  target 
readiness,  especially  dealing  with  resistance  and  the  responses  to 
positive  and  negative  change. 

The  SEPG  must  keep  working  with  both  the  MSG  and  the  line  orga¬ 
nizations  to  ensure  that  the  commitment  to  install  and  institutional¬ 
ize  the  change  exists  and  is  strong  enough.  The  MSG  must  secure  the 
commitment  of  the  development  organization  and  cascade  this  com¬ 
mitment  down  to  the  line  organizations.  The  line  organization  man¬ 
ager  must  secure  the  commitment  of  the  project  members  to  imple¬ 
ment  the  change  and  get  commitments  from  the  SEPG  for  support 
during  the  transition. 

The  SEPG  will  be  primarily  responsible  for  technology  transition  of 
the  change  into  the  line  organization.  The  MSG  and  SEPG  commu¬ 
nicate  the  rollout  strategy  and  plan  and  specific  process  changes  to 
the  development  organization.  The  SEPG  works  closely  with  the 
line  organization  to  integrate  the  changes  into  the  line  organization’s 
plans  and  activities. 

•  The  changes  are  integrated  into  the  organization’s  process  archi¬ 
tecture. 
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Deploy  Improvements 


•  A  rollout  strategy  and  plan,  which  integrates  the  installation  plan 
created  in  the  previous  section  with  the  overall  SPI  strategy,  has 
been  created  and  approved  by  the  MSG  and  the  development  or¬ 
ganization’s  senior  management  (it  helps  if  these  are  same). 

•  Specific  process  improvement  materials  are  ready  for  develop¬ 
ment  teams  to  use. 

•  Training  and  ongoing  support  has  been  arranged  for  specific 
process  improvements. 

Exit  Criteria  The  rollout  strategy  and  plan  is  fully  executed. 

The  process  improvement  is  institutionalized  in  the  line  organiza¬ 
tion. 

Tasks  The  subtasks  for  6.0,  Deploy  Improvements,  are 


Subtask 

Page 

Number 

6.1:  Brief  Entire  Organization 

129 

6.2:  Refine  Rollout  Strategy  and  Plan 

130 

6.3:  Brief  Project 

131 

6.4:  Tailor  Project  Rollout  Strategy  And  Plan 

132 

6.5:  Train  Project 

133 

6.6:  Install  Improvement 

135 

6.7:  Use  and  Evaluate  Improvement 

137 

6.8:  Refine  Deployment  for  Next  Project 

138 

6.9:  Ensure  Long-Term  Support 

139 

6.10:  Transition  to  Long-Term  Support 

140 

6.11:  Evaluate  Deployment 

141 
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Figure  6-1:  Gantt  Chart  Showing  Phased  Deployment  Across  an  Organization. 


6.0  Deploy  Improvements 

6.1  Brief  Entire  Organization 


6.1 

Brief  Entire  Organization 

Purpose 

SEPG  and  MSG  process  owners  brief  the  development  organization 
on  the  change  and  the  strategy  for  implementing  the  change.  The  de¬ 
velopment  organization  should  have  been  kept  informed  on  the 
progress  of  the  working  group  during  the  solution  development 
phase.  The  purpose  of  this  briefing  will  be  to  announce  to  the  orga¬ 
nization  the  formal  adoption  of  the  change  (or  set  of  changes),  ex¬ 
plain  the  rationale  for  adopting  the  change,  and  explain  the  strategy 
for  deploying  the  change  across  the  organization.  The  MSG  process 
owner  is  the  primary  sponsor  for  the  change  and  must  give  (or  lead) 
the  briefing  to  show  maximum  support  for  the  changes. 

Objectives 

•  Infonn  the  organization  about  changes  in  policy  because  of  the 
adoption  of  process  improvement(s). 

•  Infonn  the  organization  about  the  strategy  for  adoption,  the  ben¬ 
efits  of  the  change,  and  the  linkage  to  the  organization’s  business 
goals  and  needs. 

Entry  Criteria 

Process  improvement  included  (i.e.  documented)  in  the  organiza¬ 
tion’s  process  architecture. 

Inputs 

•  Briefing  kit/infonnation. 

•  Deployment  strategy. 

Exit  Criteria 

Organization  briefing  completed. 

Outputs 

Feedback  from  the  organization  on  the  deployment 
strategy. 

Tasks 

•  Plan  and  schedule  briefings.  The  briefings  should  be  planned 
and  scheduled  to  cover  the  entire  organization. 

Conduct  briefings. 

•  Gather  feedback  from  briefing  participants. 

Revise  future  briefings  based  on  feedback. 
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6.2 


Refine  Rollout  Strategy  and  Plan 


Purpose  Based  on  feedback  from  individual  projects  and  the  line  organiza¬ 

tion  as  a  whole,  the  SEPG  and  MSG  process  owners  modify  the  roll¬ 
out  strategy  and  plan  to  better  accommodate  the  organization’s 
needs. 

Objectives  Clarify  and  refine  rollout  strategy  and  plan,  communicate  to  organi¬ 

zation. 


Entry  Criteria 


Exit  Criteria 


Outputs 

Tasks 


Incorporate  lessons  learned  from  the  present  deployment. 

•  Feedback  has  been  provided  from  strategy  briefings  with  the  en¬ 
tire  organization  to  modify  the  rollout  strategy  and  plan. 

•  Rollout  strategy  and  plan. 

•  Rollout  strategy  and  plan  is  fully  refined.  (Refinement  continues 
in  parallel  with  the  other  tasks  in  this  phase.  See  Figure  6-1  on 
page  128). 

•  Revised  rollout  strategy  and  plan. 

•  Gather  feedback  from  other  tasks  in  this  section. 

•  Distill  lessons  learned  and  desired  modifications  from  feedback. 

•  Incorporate  lessons  learned  in  rollout  strategy  and  plan. 

•  Implement  next  task  (or  same  task  on  next  project)  with  new 
rollout  strategy  and  plan. 

•  Communicate  broad  changes  to  entire  organization. 
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6.3 


Brief  Project 


Purpose  SEPG  and  MSG  process  owners  brief  individual  organization 

projects  on  the  specifics  of  the  change  (what  it  is,  why  it  is  needed, 
why  they  are  to  do  it  at  this  specific  time,  etc.).  More  detail  about  the 
process  improvement  should  be  provided  to  the  organization  project 
at  the  point  when  it  will  be  expected  to  adopt  the  change  (projects 
will  probably  adopt  at  different  times  and  rates). 

Objectives  Describe  how  the  process  improvement  is  expected  to  fit  into  the 

project. 


Entry  Criteria 
Inputs 
Exit  Criteria 


Tasks 


•  Briefing(s)  of  the  entire  organization  have  been  completed. 
Rollout  strategy  and  plan. 

•  Project  understands  need  for  change  and  content  of 
changes. 

Plan  and  schedule  project  briefings. 


•  Tailor  briefing  to  specific  project  and  set  of  changes. 
Conduct  briefings. 

•  Gather  feedback  from  briefings  to  refine  deployment. 
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6.4  Tailor  Project  Rollout  Strategy  And  Plan 


6.4 


Tailor  Project  Rollout  Strategy  And  Plan 


Purpose  SEPG  and  project  managers  in  the  organization  fill  in  the  rollout 

strategy  and  plan  template  for  the  specific  changes  to  be  integrated, 
in  the  context  of  the  overall  line  organization’s  plan(s).  The  process 
improvement  is  tailored  to  the  project’s  environment  and  circum¬ 
stances.  There  will  be  additional  tailoring  as  the  project  continues  to 
use  the  improvement. 

Objectives  Tailor  the  process  improvement  plans  to  fit  the  project. 


Entry  Criteria 
Inputs 
Exit  Criteria 
Outputs 
Tasks 


Project  briefings  completed. 

•  Installation  plan  template. 

•  Project  agreement  with  tailored  installation  plan. 

•  Tailored  installation  plan. 

•  Using  installation  plan  template,  fill  in  appropriate  dates,  re¬ 
sources,  costs,  names,  etc.,  specific  to  this  project’s  installation. 


•  Review  the  tailored  installation  plan  with  the  project,  getting 
buy-in  from  affected  targets  for  implementation. 

•  Review  tailored  installation  plan  with  MSG. 
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6.5  Train  Project 


Purpose  The  changes  will  require  new  skills  and  knowledge  to  be  acquired 

by  the  line  organization.  To  provide  the  maximum  benefit  to  the  line 
organization  members,  training  and  practice  must  be  integrated  into 
the  project  plans.  SEPG  and  line  organization  managers  arrange 
training  and  detailed  briefings  for  line  personnel  in  (new  process, 
methods,  tools,  etc. 

Although  the  tasks  6.5  (Train  Project),  6.6  (Install  Improvement), 
and  6.7  (Use  and  Evaluate  Improvement)  appear  to  be  linear,  they 
are  usually  done  somewhat  in  parallel,  and  may  take  some  iteration. 
For  example,  a  tool  may  have  to  be  installed  for  training  to  effective¬ 
ly  be  provided  for  it.  Additionally,  it  may  not  be  possible  to  identify 
certain  needed  skills  until  their  absence  becomes  apparent.  Although 
the  order  of  these  tasks  represents  an  ideal  situation,  the  actual  im¬ 
plementation  must  be  detennined  by  the  actual  situation  and  envi¬ 
ronment. 

Objectives  •  Plan  the  training  for  the  project. 

•  Schedule  instructors  and  briefers. 

Set  up  support  relationships  for  the  project. 

Entry  Criteria  •  Project  agrees  to  installation  plan. 

•  Training  resources  are  available  to  project. 

Inputs  •  Installation  plan  for  project. 

Exit  Criteria  •  Project  is  trained  in  specifics  of  this  process  change. 

•  Project  has  ongoing  support  for  installing  and  using  changes. 

Outputs  •  Completed  training  plan. 

Modified  support  agreements  that  include  project. 
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6.5  Train  Project 


Tasks 


Assess  project  skills  and  knowledge  in  area  of  change. 

•  Plan  curriculum  to  meet  skills  and  training  needs  of  people  in  the 
project. 

Schedule  courses  and  enroll  people  from  project. 

Conduct  courses. 

•  Reassess  project  skills  and  knowledge,  retrain  as  necessary. 
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6.6  Install  Improvement 


6.6  Install  Improvement 


Purpose  Before  a  new  tool,  method,  or  process  can  be  used,  the  associated 

supporting  environment  must  be  installed.  Various  projects  in  the 
line  organization  must  tailor  the  solution  to  fit  their  environments 
and  needs.  The  installation  is  when  the  actual  tailoring  is  perfonned; 
the  tailoring  is  planned  for  in  Step  6.4,  Tailor  Project  Rollout  Strat¬ 
egy  And  Plan  (page  132).  For  lower  maturity  organizations  in  which 
there  is  more  variation  across  the  line  organization,  more  tailoring  to 
accommodate  individual  needs  will  be  required.  As  the  organization 
moves  up  the  maturity  ladder,  less  local  tailoring  is  required  for  or¬ 
ganization-wide  improvements. 

Objectives  Ensure  that  the  local  project  installs  and  can  successfully  use  the 

process  improvement. 

Entry  Criteria  •  Installation  plan  for  project  is  approved. 

Project  included  in  support  contracts. 

•  Project  trained  in  specifics  of  process  improvement 

Inputs  •  Installation  plan  and  support  plans  for  the  project. 

•  Tools,  artifacts,  and  documentation  to  support  implementation 
of  process  improvement. 

Exit  Criteria  •  Project  has  sufficient  support  for  the  improvement. 

Tasks  Specific  installation  tasks  vary  widely  depending  on  the  nature  of 

the  change.  New  tools  require  software  upgrades,  installations,  file 
system  changes,  etc.,  while  a  new  procedure  requires  an  update  to 
hard-  and  soft-copy  documentation.  The  tasks  listed  here  are  very 
generic  and  shouldn’t  limit  the  actual  installation. 

Plan  and  schedule  installation,  upgrades,  etc.,  when  they  won’t 
affect  critical  project  tasks. 
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6.6  Install  Improvement 


Carry  out  installation,  upgrade,  etc.,  verifying  correct  new  oper¬ 
ation  in  the  given  environment.  Clean  up  any  problems  associat¬ 
ed  with  the  installation. 

•  W alk  through  new  operation  with  affected  people  in  the  changed 
environment.  Clean  up  any  problems  associated  with  the  instal¬ 
lation. 

•  Run  through  new  operation  at  normal  speed.  Clean  up  any  prob¬ 
lems  associated  with  the  installation. 

•  Review  installation  with  project  for  final  approval. 
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6.7  Use  and  Evaluate  Improvement 


6.7 


Use  and  Evaluate  Improvement 


Purpose  The  line  organization  starts  using  the  new  process,  monitored  by  the 

SEPG.  At  this  point,  the  new  process  should  be  measured  to  validate 
and  refine  the  process  installation.  The  metrics  collected  during  the 
solution  development  pilots  should  also  be  used  during  improve¬ 
ment  deployment. 

Objectives  •  Run  the  project  using  the  new  or  modified  process. 


•  Reinforce  the  new  skills  and  knowledge. 

Support  the  project  in  the  new  skills  and  knowledge. 

Entry  Criteria  •  Changes  installed  for  use. 

Inputs  •  New  environment  incorporating  process  improvement. 

Exit  Criteria  •  Project  has  institutionalized  the  improvement. 

Outputs  •  Process  evaluation  metrics. 

Tasks  •  Project  uses  the  new  environment  in  the  normal  course  of  its 

work. 

•  Proj  ect  personnel  record  process  metrics  while  using  the  new  en¬ 
vironment. 

SEPG  monitors  project  to  ensure  proper  usage,  giving  support 
and  additional  training  where  necessary. 
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6.8  Refine  Deployment  for  Next  Project 


6.8 


Refine  Deployment  for  Next  Project 


Purpose 


Objectives 


The  line  organization  and  SEPG  adjust  implementation  based  on  the 
data  collected  while  monitoring  the  process  adoption  of  the  previous 
project.  Based  on  the  measures  collected  during  execution,  the  pro¬ 
cess  improvement  may  have  to  be  modified  for  adoption  by  other 
projects. 

Reduce  sources  of  variation  in  new  process. 


Entry  Criteria 
Inputs 


Exit  Criteria 


Outputs 


Tasks 


Incorporate  lessons  learned  from  previous  project  installation 
for  next  project. 

Previous  project  has  installed  and  evaluated  new  process. 

Installation  plan  for  the  project. 

Organization  rollout  strategy  and  plan. 

Installation  plan  template. 

Lessons  learned  incorporated  into  installation  plan  template  and 
organization  rollout  strategy  and  plan. 

Revised  installation  plan  template. 

Revised  organization  rollout  strategy  and  plan. 

Ensure  that  problems  are  caused  by  the  process  and  are  not  arti¬ 
facts  of  some  other  problem. 

Review  tailorings  to  see  if  they  should  become  standardized. 
Update  installation  plan  template  and  organization  rollout  strat¬ 
egy  and  plan  as  appropriate. 
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6.9  Ensure  Long-Term  Support 


6.9 


Ensure  Long-Term  Support 


Purpose  After  adoption,  the  project  will  need  ongoing  support  to  maintain  the 

process  improvement  in  its  project.  Long-term  needs  must  be  antic¬ 
ipated  to  ensure  adequate  support. 

Objectives  •  Tailor  a  support  contract  for  the  project  (possibly  directly  with 

solution  providers). 


Entry  Criteria 
Inputs 
Exit  Criteria 


Outputs 


Ensure  long-range  funding  for  support. 

Generic  support  agreement  with  solution  providers  in  place. 
Support  contracts. 

Project  included  in  long-term  support  agreements  with  solution 
providers. 

Long-tenn  support  funded. 

Revised  support  contracts. 


Tasks 


Assess  project-specific  needs  for  long-term  support. 
Revise  support  contracts  to  include  project-specific  needs. 
Secure  funding  for  long-term  project  support. 
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6.10 


Transition  to  Long-Term  Support 


Purpose 


Objectives 


The  process  improvement  should  not  require  constant  vigilance;  if  it 
does,  it  should  to  be  retuned  (or  rethought).  The  development  team 
should  be  able  to  continue  without  a  lot  of  guidance  and  support,  but 
should  be  able  to  call  in  expertise  when  needed.  When  the  line  orga¬ 
nization  demonstrates  that  it  can  repeatedly  execute  the  new  process, 
SEPG  involvement  falls  back  to  an  on-call  support  role,  and  the 
long-term  support  group  takes  over. 

Support  the  line  organization  in  normal  use  of  the  process. 


Entry  Criteria 


Changes  rolled  out  to  all  projects  in  the  organization. 


Inputs 


Long-tenn  support  contracts  and  funding  in  place. 
Support  contracts. 


Exit  Criteria 


New  environment  makes  existing  contracts  obsolete. 


Tasks  •  Line  organization  calls  on  long-term  support  instead  of  SEPG 

when  problems  arise,  new  training  is  needed,  specific  tailoring 
is  required,  etc. 

•  SEPG  monitors  long-term  support  contracts  to  ensure  adequate 
support  for  line  organization. 

•  MSG  periodically  reviews  long-term  support  to  ensure  that 
proper  funding  and  contractual  commitments  are  being  met. 
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6.11 


Evaluate  Deployment 


Purpose 


Objectives 


Entry  Criteria 


Inputs 


The  line  organization  conducts  a  retrospective  evaluation  of  the  de¬ 
ployment  use  of  the  new  process  during  their  projects,  giving  the 
feedback  to  the  SEPG  to  further  refine  the  installation  and  deploy¬ 
ment  processes.  By  providing  feedback  to  the  SEPG,  the  methods 
and  techniques  used  during  the  implementation  can  be  incorporated 
into  the  next  round  of  improvements. 

Gather  lessons  learned  from  deploying  improvements  and  apply  to 
future  deployments. 

Organization  has  fully  deployed  the  improvement  and  has  been  us¬ 
ing  it  for  a  few  cycles. 

•  Organization  rollout  strategy  and  plan. 


•  Installation  plans  for  projects. 

•  Process  metrics  reports. 

Exit  Criteria  •  Lessons  from  deployment  captured. 

•  SEPG  revises  generic  rollout  strategy  and  plans  and  installation 
plan  templates. 

Outputs  •  Retrospective  report. 

•  Revised  generic  rollout  strategy  and  plans  and  installation  plan 
templates. 

Tasks  •  Plan  and  schedule  retrospective  meeting(s). 

Survey  organization  to  collect  top-level  lessons,  issues,  and  re¬ 
maining  actions. 

Compile  retrospective  survey  results. 

•  Conduct  retrospective  meeting  to  clarify  findings. 

•  Package  retrospective  findings  and  review  with  organization. 
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•  Revise  generic  templates  for  rollout  strategy  and  plans  and  in¬ 
stallation  plans. 

•  Develop  action  plan  to  resolve  outstanding  issues  and  finish  re¬ 
maining  actions. 

•  Execute  action  plan  and  review  results  with  organization. 
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A.O  .Taxonomy  of  Software  Process 

Improvement  Plans  and  Charters 


introduction  This  taxonomy  describes  the  planning  documents  built  and  used  in 

the  software  process  improvement  (SPI)  roadmap. 

Plan  Summary  (Parenthetical  numbers  in  the  Plan  Name  column  refer  to  the  section 

in  this  appendix  in  which  the  document  is  explained  in  more  detail) 


Plan  Name 

Purpose 

Phase  Where 
Generated 

Responsibility 

Audience 

SPI  Implementation 
Plan  (A.l) 

Provide  information  to 
launch  SPI 

1 .0  Initiate  Software  Process 
Improvement 

1.3  Build  a  Proposal 

Software 
engineering 
process  group 
(SEPG)  leader 

Management 
steering  group 
(MSG), 
organization 

MSG  Charter  (A.2) 

Define  mission  of 

MSG 

1.0  Initiate  Software  Process 
Improvement 

1.6  Establish  the  Software 
Process  Improvement 
Infrastructure 

2.0  Manage  the  Software 
Process  Improvement 

Program 

SPI  champion 

MSG 

SEPG  Charter  (A.3) 

Define  mission  of 

SEPG 

1.0  Initiate  Software  Process 
Improvement 

1.6  Establish  the  Software 
Process  Improvement 
Infrastructure 

2.0  Manage  the  Software 
Process  Improvement 

Program 

MSG  chair 

MSG,  SEPG 

Table  A-1:  SPI  Roadmap  Plan  Summary 
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Plan  Name 

Purpose 

Phase  Where 
Generated 

Responsibility 

Audience 

Organization 
Strategic  Plan  for 

SPI  (A. 4) 

Framework  for  SPI  in 
context  of  the 
organization’s  business 

1.0  Initiate  Software  Process 
Improvement 

1.3  Build  a  Proposal 

3.0  Build  Software  Process 
Improvement  Strategy 

MSG  chair 

MSG, 

organization 

Organization 

Communication 

Plan  (A.5) 

Creates  organization- 
wide  awareness  and 
involvement  with  the 
SPI  program 

1 .0  Initiate  Software  Process 
Improvement 

1.4  Educate  and  Build 

Support 

3.0  Build  Software  Process 
Improvement  Strategy 

SEPG  chair 

MSG, 

organization 

Baseline  Action 

Plan  (A.6) 

Specify  charter,  scope, 
and  deliverables  for  a 
specific  baseline  effort 

4.0  Baseline  Current  State 

MSG  chair,  TWG 
leader 

MSG,  SEPG, 
technical 
working  group 
(TWG) 

SPI  Strategic 

Action  Plan  (A.7) 

SPI  framework  in 
terms  of  organization 
business  direction  for 
short  and  long  term 

3.0  Build  Software  Process 
Improvement  Strategy 

MSG  chair 

MSG, 

organization 

Tactical  Action 

Plan  (A.8) 

Specify  charter,  scope, 
and  deliverables  for 
specific  improvement 
efforts 

2.0  Manage  the  Software 
Process  Improvement 

Program 

MSG  chair,  TWG 
leader 

MSG,  SEPG, 
TWG 

Pilot  Plan  (A. 9) 

Define  steps  to  install 
an  improvement  in  a 
subunit  of  the 
organization 

6.0  Deploy  Improvements 

TWG  leader 

MSG,  SEPG, 
TWG,  subunit 
managers  and 
staff 

Rollout  Strategy 
and  Plan  (A.10) 

Define  strategy  and 
plan  for  extending 
improvement  to 
organization 

6.0  Deploy  Improvements 

MSG  chair 

MSG,  SEPG, 
TWG, 

organization 
managers  and 
staff 

Table  A-1:  SPI  Roadmap  Plan  Summary 
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A.1 


SPI  Implementation  Plan 


Purpose  Define  specific  tasks,  schedules,  responsibilities,  milestones,  etc., 

involved  in  launching  the  SPI  program  from  baselining  through  the 
completion  of  the  SPI  strategic  action  plan. 

Contents  •  Tailored  version  of  the  roadmap,  specific  to  the  particular  client 

organization. 


•  Infrastructure  description  with  role,  responsibilities,  and  inter¬ 
faces  defined. 

•  Work  breakdown  with  task  description  [ETVX  (entry,  task,  val¬ 
idation,  exit  criteria)  form],  deliverables,  and  estimated  resourc¬ 
es. 

•  Training  and  communication  activities  needed. 

•  Estimated  schedule  with  responsibilities. 

•  Assumptions  and  risks  in  SPI  program. 
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A.2  MSG  Charter 


Purpose 

Contents 


Define  mission  of  MSG. 

Purpose  and  objectives  of  MSG. 

•  Roles  and  responsibilities  of  members. 

•  Relationship  to  SEPG,  existing  management  structures. 
Reporting  and  approval  process. 

Resources  and  meeting  schedules. 
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A. 3  SEPG  Charter 


A.3 

SEPG  Charter 

Purpose 

Define  mission  of  the  SEPG. 

Contents 

Purpose  and  objectives  of  SEPG. 

•  Roles  and  responsibilities  of  members. 

•  Membership:  criteria,  assignment,  and  rotation. 

•  Relationship  to  MSG,  existing  management  structures,  TWGs. 
Reporting  and  approval  process. 

Resources  and  meeting  schedules. 

•  Training  requirements. 
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A.4  Organization  Strategic  Plan  for  Software 

Process  Improvement  (SPI) 


Purpose  •  Provide  strategic  business  plan  for  the  organization. 

•  Provide  a  framework  for  the  SPI  program  (usually  an  initiative 
under  the  organization  strategic  plan). 

Contents  •  Introduction  to  organization  history,  product  line,  and  culture. 

•  Executive  summary. 

Vision,  mission,  and  guiding  objectives. 

•  Customer  definition. 

Goals  for  product,  process,  people;  short-term  (one  year  of  prod¬ 
uct  cycle)  and  long-tenn  (three  to  five  years). 

•  Assumptions  and  risks. 

•  Infrastructure  with  roles,  responsibilities,  and  interfaces  defined. 
Criteria  and  measures  of  success. 

High-level  description  of  competencies  to  be  sustained  and  de¬ 
veloped 
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A.5  Organization  Communication  Plan 


Purpose  Create  an  awareness  of  the  SPI  activity.  Describe  the  purpose  and 

the  benefits  of  the  SPI  program. 

Contents  •  Introduction  and  overview. 

•  Communication  plan  goals. 

•  Assumptions  and  risks. 

•  Communications  agenda. 

Messages,  media,  and  audiences. 

Resources  and  schedules. 
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A.6 


Baseline  Action  Plan 


Purpose 

Contents 

•  Detailed  description  of  the  major  activities  and  deliverables. 
Interfaces  and  dependencies  with  other  groups. 

Work  breakdown  structure  and  schedules. 

•  Assumptions,  risks  and  risk  management. 


Specify  charter,  scope,  and  deliverables  for  a  specific  baseline  ef¬ 
fort. 

Objectives/charter  of  the  baseline  working  group. 
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A.7 


SPI  Strategic  Action  Plan 


Purpose  Describes  a  SPI  framework  in  terms  of  organization  business  direc¬ 

tion  for  the  short  and  long  tenn,  as  developed  from  the  baselines  and 
organizational  vision  and  strategic  plan. 

Contents  For  an  explanation  of  the  content  categories  below,  see  Section  C.4, 

SPI  Strategic  Action  Plan  (page  184)  in  Appendix  C.O,  Charters  and 
Templates. 


Overview 

•  Executive  summary. 

•  Process  improvement  goals. 

Objectives. 

•  Assumptions  and  risks. 

•  Organization  for  process  improvement. 

•  Responsibility  matrix. 

Criteria  for  success. 

•  Improvement  agenda. 
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A.8  Tactical  Action  Plan 


Purpose  •  Identify  the  activities,  schedules  and  deliverables  of  a  TWG  that 

will  investigate  and  evaluate  a  process  for  improvement. 

Contents  For  an  explanation  of  the  content  categories  below,  see  Section  C.5, 

Tactical  Action  Plan  (page  188)  in  Appendix  C.O,  Charters  and 
Templates. 

Introduction/o  vervie  w . 

Objectives/charter. 

Detailed  description. 

Resources. 

Interfaces/dependencies . 

•  Work  breakdown  structure  (WBS). 

Schedule. 

•  Risks. 

•  Status/monitoring. 
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A.9 


Pilot  Plan 


Purpose  •  Defines  strategy  for  initiating  an  improvement  within  a  project 

or  subunit  of  an  organization. 

Contents  The  pilot  plan  is  similar  to  the  generic  installation  plan  in  Section 

C.6,  Installation  Plan  (page  188),  tailored  for  piloting. 


•  Introduction/overview:  identifies  the  recommendation  that  this 
pilot  installation  is  addressing. 

Goals,  objectives,  and  purpose:  describes  the  purpose  of  this 
TWG. 

•  Technology  description;  may  be  slightly  different,  since  it  also 
evaluates  an  installation  process. 

•  Evaluation  procedures:  describes  how  to  evaluate  and  tailor  this 
pilot  installation  into  an  organizational  installation  and  rollout 
strategy  and  plan. 

•  Work  breakdown  structure  (WBS):  break  overall  task  into  sub¬ 
tasks. 

Schedule:  defines  expected  milestones. 

Resources:  describes  personnel,  money,  computer  resources, 
etc. 

•  Risks:  provide  basis  for  contingency  planning. 

•  Status/monitoring  mechanisms:  describes  how  status  is  reported 
and  progress  monitored. 
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A.10  Rollout  Strategy  and  Plan 


Purpose  •  Defines  strategy  for  rolling  out  all  improvements  across  the  or¬ 

ganization,  based  on  lessons  learned  from  pilot  installation. 


•  Defines  criteria  for  detennining  what  parts  of  the  organization 
will  install  improvements  and  when. 

•  Defines  what  specific  improvements  will  be  installed,  where, 
and  when. 

Contents  The  rollout  strategy  and  plan  is  similar  to  the  generic  installation 

plan  in  Section  C.6,  Installation  Plan  (page  188),  tailored  for  rollout. 

Introduction/o  vervie  w . 

Goals,  objectives  and  purpose:  describes  what  will  be  accom¬ 
plished,  why  it  is  needed  and  who  it  applies  to. 

Technology  description. 

•  Tailoring:  provides  guidelines  on  how  and  when  to  do  any  tailor¬ 
ing  to  technology  and/or  plan. 

•  Education  and  training:  describes  what  training  (formal/infor¬ 
mal)  will  be  required. 

•  Evaluation  procedures:  describes  how  to  evaluate  installation 
and  use. 

•  Work  breakdown  structure  (WBS):  breaks  overall  task  into 
smaller,  more  manageable  subtasks. 

Schedule:  defines  key  milestones. 

Resources:  describes  resources  required. 

Interfaces/dependencies . 

•  Risks. 

Status/monitoring:  describes  how  status  will  be  reported  and 
progress  monitored. 
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B.O  Components  of  the  Software 

Process  Improvement 
Infrastructure 


Objectives  This  appendix  provides  a  brief  discussion  the  three  principal  compo¬ 

nents  of  the  software  process  improvement  (SPI)  infrastructure.  The 
reader  should  become  familiar  with  the  roles  and  responsibilities 
that  are  outlined  for  each  component. 


The  identified  roles  and  responsibilities  are  only  a  starting  point; 
they  can  be  expanded  or  contracted  to  fit  specific  organizations. 

In  some  instances  benefit  can  be  gained  from  having  additional  com¬ 
ponents  to  the  SPI  infrastructure.  These  components  are  described  in 
B.4,  The  Software  Process  Improvement  Advisory  Committee  (SPI- 
AC)  (page  169)  and  B.5,  The  Executive  Council  (EC)  (page  171). 
Typically  these  additional  components  are  formed  in  organizational 
environments  that  are  either  very  large  and/or  have  wide  geograph¬ 
ical  disbursement. 

Purpose  Executive  management  will  determine  the  size,  scope,  and  responsi¬ 

bilities  of  the  infrastructure  to  support  the  software  process  improve¬ 
ment  (SPI)  program.  Taking  into  account  such  things  as  the  organi¬ 
zation’s  size,  needs,  strategy,  and  culture  management  will  deter¬ 
mine  the  number  of  layers,  authority,  and  responsibility  for  each 
component  and  who  should  be  represented  within  the  infrastructure. 

To  build  buy-in  for  the  SPI  program,  the  infrastructure  is  created  and 
staffed  with  representatives  from  all  parts  of  the  organization.  In¬ 
volving  all  parts  of  the  organization  builds  a  feeling  of  ownership 
and  participation  in  the  program. 

An  example  of  an  infrastructure  is  shown  in  Figure  B- 1  on  page  1 60. 
The  first  of  the  three  components  shown  is  a  management  steering 
group  (MSG),  whose  membership  is  drawn  from  the  organization’s 
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existing  management  structure.  Reporting  to  the  MSG  is  the  soft¬ 
ware  engineering  process  group  (SEPG).  The  leader  of  the  SEPG 
also  participates  as  a  non-voting  member  and  sometimes  serves  as 
the  facilitator  for  the  MSG.  Membership  of  the  SEPG  is  drawn  from 
the  practitioners  who  are  working  on  the  projects  in  the  organization. 
Depending  on  the  size  of  the  organization,  SEPG  membership  can 
be  on  a  full-time,  part-time,  or  some  combination  of  full-  and  part- 
time  basis.  In  all  cases  there  should  be  a  full-time  person  leading  the 
SEPG.  Reporting  to  the  MSG  with  dotted-line  relationship  to  the 
SEPG  are  the  technical  working  groups  (TWGs).  Membership  on 
the  TWGs  is  drawn  from  those  areas  of  the  organization  that  would 
be  affected  by  any  recommendations  for  improvement  change  made 
by  the  TWG. 


Figure  B-1:  Example  of  Infrastructure 

The  components  that  make  up  the  SPI  infrastructure  each  have  a  spe¬ 
cific  role  in  the  SPI  program.  The  infrastructure  that  is  created 
should  be  sized  based  on  the  needs  of  the  SPI  program.  Care  should 
be  taken  that  the  size  and  shape  of  the  infrastructure  does  not  get  in 
the  way  of  the  SPI  program.  Each  component  has  a  scope  of  clearly 
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defined  duties  and  responsibilities.  Figure  B-2  below  is  an  expan¬ 
sion  of  the  infrastructure  to  support  a  SPI  program. 


Figure  B-2:  Expansion  of  Infrastructure  in  Figure  B-1 
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B.1 


The  Management  Steering  Group  (MSG) 


Objectives 


Link  SPI  program  to  organization’s  vision  and  mission. 


•  Allocate  resources  and  insure  work  distribution. 

•  Monitor  implementation  results  and  provide  corrective  actions 
as  necessary. 

Purpose  The  MSG  is  made  up  of  the  management  team  that  represents  the 

highest  level  of  management  in  the  organization.  Its  purpose  is  to 
guide  the  SPI  implementation  activities  in  the  organization.  The 
MSG  will  establish  the  goals  and  objectives  and  set  the  direction  and 
priorities  for  the  SPI  program.  The  MSG  should  also  apply  improve¬ 
ment  activities  to  the  existing  management  processes. 

The  MSG  will  supply  the  resources  necessary  to  carry  out  the  SPI 
program.  It  will 

•  Charter  TWGs  for  specific  process  improvement. 

•  Approve  training  to  support  the  SPI  program. 

•  Determine  the  measurement  and  success  criteria  used  to  evaluate 
the  program. 

The  MSG  will  also  serve  to  resolve  issues  that  arise  during  the  SPI 
program  that  cannot  be  handled  by  the  SEPG  and  TWGs.  The  MSG 
removes  barriers  to  the  SPI  program  and  creates  a  recognition  and 
reward  structure  to  recognize  the  efforts  of  the  people  involved  in 
accomplishing  the  process  improvement. 

The  MSG  is  made  up  of  the  senior  site  manager,  as  chair,  and  other 
members  drawn  from  his  or  her  management  team.  The  MSG  meets 
monthly,  probably  more  frequently  in  the  early  stages  of  the  SPI  pro¬ 
gram,  moving  toward  a  fixed  monthly  schedule.  It  would  be  a  good 
practice  to  have  the  SEPG  leader  be  the  facilitator  for  the  MSG 
meetings.  The  meeting  is  mandatory  for  all  MSG  members  and  op¬ 
erates  formally  with  agendas,  minutes  and  action  items.  By  its  ac- 


162 


CMU/SEI-95-UG-001 


B.O 

B.1 


Tasks 


Components  of  the  Software  Process  Improvement  Infrastructure 
The  Management  Steering  Group  (MSG) 


tions  the  MSG  can  demonstrate  to  the  organization  its  commitment 
and  support  of  the  SPI  program. 

The  MSG  will  exist  for  the  duration  of  the  SPI  program.  Members 
may  change  as  the  organization  changes  and  matures,  but  the  roles 
and  responsibilities  to  the  SPI  program  will  remain. 

Activities  that  will  be  performed  by  the  MSG  include 

•  Approve  SPI  strategic  action  plans. 

•  Establish  TWGs. 

•  Draft  TWG  charters. 

•  Draft  tactical  action  plan. 

•  Hold  monthly  meetings  (2-4  hours). 

•  Review  results  of  baselining  activities. 

•  Allocate  resources. 

Monitor  working  group  progress. 

Approve  broad  installation  of  improvements,  dependent  on  re¬ 
sults  of  pilot  activities. 

Report  progress  to  executive  council  (EC). 

•  Facilitate  EC  meetings. 
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B.2 


The  Software  Engineering  Process  Group 
(SEPG) 


Objectives 


Facilitate  SPI  throughout  the  organization. 


Purpose 


Facilitate  SPI 
Throughout  the 
Organization 


•  Track  and  report  status  of  SPI  programs. 

•  Serve  as  focal  point  for  organizational  learning. 

The  SEPG  is  the  focal  point  for  the  organization’s  SPI  program.  It  is 
responsible  for  and  facilitates  the  activities  that  relate  to  software 
process  improvement,  such  as  action  planning,  process  improve¬ 
ment,  technology  improvement,  and  other  activities.  The  SEPG  also 
exchanges  information  between  the  organization’s  SPI  program  and 
the  programs  of  other  SEPGs  across  the  country.  The  SEPG  coordi¬ 
nates  and  plans  all  of  the  organization’s  SPI  programs.  The  SEPG 
also  leads  the  organization’s  improvement  efforts. 

The  SEPG  maintains  an  organizational  awareness  of  the  overall  SPI 
effort  and  serves  as  a  facilitator  to  insure  the  successful  completion 
of  improvement  activities.  As  the  catalyst  for  the  SPI  program,  one 
of  the  biggest  challenges  for  the  SEPG  is  to  maintain  the  motivation 
and  enthusiasm  for  process  improvement  across  and  between  all  lev¬ 
els  of  the  organization. 

Facilitating  SPI  throughout  the  organization  means  that  the  SEPG 
has  to  obtain  and  maintain  management  support  for  the  initiative  at 
all  levels  and  across  all  functionality.  The  SEPG  is  assisted  in  ac¬ 
complishing  this  by  working  with  the  MSG  to  demonstrate  commit¬ 
ment  to  practitioners  and  management  of  the  organization. 

The  SEPG  will  facilitate  software  process  assessments  and,  along 
with  the  organization’s  management  and  practitioners,  will  develop 
the  SPI  strategic  action  plan  to  guide  the  efforts.  The  SEPG  will  also 
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Provide  Process 
Consultation 


Track  and  Report 
SPI  Progress 


Serve  as  Focal 
Point  for 
Organizational 
Learning 


Size 


facilitate  other  baselining  activities  to  provide  definition  for  existing 
process  definitions  and  measurement  activities. 

The  SEPG  supports  the  line  managers  and  development  projects  by 
providing  process  consultation  when  required.  It  also  works  closely 
with  the  line  managers  and  projects  to  provide  guidance  and  support 
when  new  improvement  changes  are  being  introduced.  It  can  assist 
the  line  organizations  in  evaluation  of  new  technology  and  can  also 
help  plan  for  the  introduction  and  transition  to  new  technologies. 

Another  activity  of  the  SEPG  is  to  monitor  all  of  the  SPI  activities 
that  are  under  way  in  the  organization.  The  SEPG  will  report  the  sta¬ 
tus  of  the  various  improvement  activities  that  are  in  progress  to  the 
MSG.  The  SEPG  should  establish  and  maintain  a  process  database 
for  retaining  the  various  artifacts  that  result  from  the  improvement 
activities.  Timely  reporting  of  SPI  status  will  allow  the  MSG  to 
make  informed  decisions  that  will  support  and  enhance  the  success 
of  the  SPI  program. 

The  SEPG  will  also  serve  as  the  focal  point  of  the  organization’s  SPI 
activities.  It  will  arrange  for  or  conduct  training  in  process  improve¬ 
ment  and  continuing  education  in  other  subjects  relevant  to  the  SPI 
program.  From  the  process  database,  the  SEPG  will  be  able  to  main¬ 
tain  and  disseminate  lessons  learned  as  a  result  of  the  SPI  program. 

The  SEPG  should  be  staffed  at  a  full-time  level  that  is  equivalent  to 
1  -  3%  of  the  organization’s  development  staff.  In  some  smaller  or¬ 
ganizations  (fewer  than  100  professionals)  at  least  one  person,  the 
SEPG  leader,  should  be  devoted  full  time  to  SEPG  responsibilities. 
From  time  to  time,  the  SEPG  will  need  additional  resources  to  func¬ 
tion  effectively. 

These  resources  can  be  “borrowed”  from  the  line  organizations  on  a 
part-time  basis.  Assignments  to  the  SEPG  are  usually  made  for  a 
fixed  period  of  time,  on  the  order  of  one  to  two  years,  after  which  the 
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Membership 


Tasks 


practitioners  return  to  their  line  organizations  and  their  place  on  the 
SEPG  is  filled  by  another  practitioner. 

Characteristics  of  members  of  the  SEPG  include  experience  as  a 
software  development  practitioner,  sound  knowledge  in  one  or  more 
domains,  and  respect  of  their  peers  in  the  line  organizations. 

The  members  must  support  the  SPI  program,  championing  it  to  the 
rest  of  the  organization.  They  must  also  have  the  capability  to  effec¬ 
tively  serve  as  agents  of  change  as  new  and  improved  processes  and 
technologies  are  introduced  to  the  organization. 

SEPG  members  are  critical  to  the  success  of  the  SPI  program.  It 
would  be  a  good  practice  for  the  MSG  to  set  up  a  screening  and/or 
interview  process  for  SEPG  membership.  This  would  help  ensure 
that  members  have  the  proper  background,  experience,  and  enthusi¬ 
asm  for  the  job. 

In  most  organizations  members  of  the  SEPG  are  on  temporary  as¬ 
signment  ranging  from  one  to  two  years.  Although  they  may  return 
to  their  regular  jobs,  the  SEPG  continues. 

Some  of  the  tasks  that  are  performed  by  the  SEPG  are 
Hold  weekly  meetings 

•  Identify  and  recommend  improvement  activities  to  MSG. 

•  Track  and  report  progress  of  improvements  to  MSG 

•  Detennine  effectiveness  of  improvements. 

•  Develop  and  maintain  process  database. 

•  Develop  training  plans  and  arrange  for  training. 

Provide  consultation  to  projects. 

•  Facilitate  software  process  assessments  (SPAs). 

•  Facilitate  MSG  meetings. 
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B.3 


The  Technical  Working  Group  (TWG) 


Objectives 


Document  current  processes. 


Assess  current  processes. 

Improve  current  processes. 

Develop  plan  to  pilot  improved  process. 

Pilot  the  new  improved  process. 

Purpose  TWGs  are  the  solution  developers  for  the  SPI  program.  They  are 

formed  to  address  a  specific  area  in  the  overall  improvement  pro¬ 
cess.  Their  responsibility  is  to  address  a  specific  area  for  process  im¬ 
provement,  and  they  are  given  a  charter,  resources,  and  authority  to 
complete  their  activity. 

The  purpose  of  a  TWG  is  to  improve  the  process  that  it  has  been 
chartered  to  evaluate  and  improve.  The  TWG  is  formed  by  the  MSG 
to  address  a  specific  process  area.  To  properly  carry  out  its  job,  the 
TWG  must  be  given  proper  guidance  by  the  MSG.  This  is  docu¬ 
mented  in  its  charter,  which  defines  a  clear  mission,  states  the  objec¬ 
tives,  and  delegates  authority  to  accomplish  the  mission.  Also  im¬ 
plied  is  a  commitment  of  necessary  resources  and  the  support  of 
management  to  get  the  job  done. 

The  TWGs  can  address  processes  at  any  level  in  the  organization. 
They  can  be  made  up  of  managers,  addressing  high-level,  cross¬ 
functional  processes,  or  they  can  be  made  up  of  practitioners,  ad¬ 
dressing  lower  level,  single-function  processes.  Key  to  the  member¬ 
ship  of  the  TWG  are  that  the  members  are  drawn  from  staff  who 

Are  knowledgeable  about  the  process  being  evaluated. 

•  Work  in  the  process. 

•  Would  be  affected  by  changes  made  for  the  improvement  of  the 
process. 
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The  leader  of  the  TWG  should  be  the  owner  of  the  process  that  is  be¬ 
ing  evaluated.  For  example,  a  TWG  formed  to  evaluate  and  improve 
the  testing  process  would  have  the  Manager  of  Testing  as  the  TWG 
leader.  Other  members  of  the  TWG  would  be  selected  to  provide  al¬ 
ternative  perspectives  to  the  process  being  studied.  Having  TWG 
members  who  are  either  customers  of  the  process  or  suppliers  to  the 
process  is  also  beneficial.  If  possible  the  members  of  the  TWG 
should  be  volunteers  as  opposed  to  being  assigned  to  the  team.  This 
will  ensure  that  the  team  members  have  an  expressed  interest  in  the 
activity.  Participation  on  a  TWG  also  provides  for  broadening  of 
support  and  additional  buy-in  to  the  improvement  activities. 

The  frequency  of  TWG  meetings  varies.  Some  teams  meet  weekly 
for  an  hour  at  a  fixed  time  and  day.  Other  teams  may  meet  every  oth¬ 
er  Tuesday  for  four  hours.  Regardless  of  the  frequency,  the  meeting 
is  mandatory  for  all  team  members,  is  very  focused,  and  is  fast  mov¬ 
ing.  The  team  follows  a  formal  agenda,  and  at  the  end  of  the  meeting 
time  is  reserved  to  evaluate  the  meeting.  It  will  take  a  few  meetings 
for  the  team  to  get  to  know  and  be  comfortable  with  each  other  be¬ 
fore  they  start  functioning  effectively.  If  possible  it  would  be  a  good 
idea  for  the  first  one  or  two  meetings  to  be  devoted  to  instruction  on 
team  concepts  and  meeting  effectiveness. 

Tasks  Activities  that  are  perfonned  by  a  TWG  include 

•  Research  problem  and  identify  solutions. 

•  Formulate  solution. 

•  Revise  tactical  action  plan  to  fit  selected  solution. 

Present  possible  solutions  to  MSG  along  with  proposed  solution. 
Select  initial  prototype  group. 

Begin  prototyping. 

Evaluate  results  of  prototype. 

•  Revise  tactical  action  plan  with  lessons  learned  from  prototype. 
This  becomes  the  rollout  strategy  and  plan. 


168 


CMU/SEI-95-UG-001 


B.O  Components  of  the  Software  Process  Improvement  Infrastructure 
B.4  The  Software  Process  Improvement  Advisory  Committee  (SPIAC) 


B.4  The  Software  Process  Improvement  Advisory 

Committee  (SPIAC) 


Objectives  The  main  objective  of  a  software  process  improvement  advisory 

committee  (SPIAC)  is  to  provide  an  organizational  forum  for  shar¬ 
ing  infonnation  regarding  the  SPI  activities  that  are  being  undertak¬ 
en  by  different  parts  of  the  organization.  Additionally  the  SPIAC  can 

•  Advise  management  on  SPI  matters. 

•  Establish  common  positions  on  critical  SPI  issues. 

•  Identify  the  benefits  of  SPI  implementations. 

•  Identify  the  requirements  for  SPI  implementations. 

•  Maintain  the  process  database  for  items  that  are  suitable  for  im¬ 
plementation  across  all  locations. 

•  Maximize  the  sharing  of  SPI  resources  across  the  organization. 

•  Participate  with  external  organizations  and  software  process  im¬ 
provement  networks  (SPINs)  for  SPI  programs. 

Purpose  The  purpose  of  the  SPIAC  is  to  support  the  long-range  process  im¬ 

provement  activities  of  the  organization  by  facilitating  interaction 
among  the  organization’s  SEPGs,  promoting  information- sharing 
and  providing  a  mechanism  for  the  SEPGs  to  address  common  prob¬ 
lems. 

The  SPIAC  can  be  a  very  valuable  resource  for  those  organizations 
that  have  multiple  SEPGs.  These  SEPGs  may  be  operating  in  the 
same  or  different  geographical  locations.  The  SPIAC  will  provide 
the  organization  a  vehicle  for  sharing  information  about  the  organi¬ 
zation’s  SPI  programs.  Each  member  site  of  the  SPIAC  will  contrib¬ 
ute  lessons  learned  and  reports  of  successful  improvement  activities, 
which  will  benefit  other  SEPGs  in  the  organization.  Much  valuable 
information  can  be  exchanged:  techniques  used  for  improvement  ac¬ 
tivities,  technology  evaluations,  vendor  experiences,  etc. 
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The  purpose  of  an  SPIAC  is  to  foster  communication.  Each  of  the 
participating  sites  has  learned  some  valuable  lessons  as  it  has  pro¬ 
gressed.  Having  a  forum  where  these  lessons  can  be  shared  along 
with  successful  improvement  activities  will  benefit  the  entire  orga¬ 
nization.  Member  sites  will  be  able  to  capitalize  on  work  that  has  al¬ 
ready  been  done  at  other  sites. 

SPIACs  should  meet  quarterly.  At  the  beginning  of  the  SPI  program, 
it  would  be  advantageous  to  meet  more  frequently  to  resolve  all  of 
the  start-up  issues  such  as  charter,  officers,  length  of  term,  etc.  Meet¬ 
ing  duration  is  at  least  one  full  day  as  there  will  be  plenty  of  work  to 
accomplish.  Occasionally  the  meeting  may  last  for  two  days. 

Overall  membership  includes  all  members  of  all  of  the  organiza¬ 
tion’s  SEPGs,  with  one  voting  member  for  each  SEPG  represented. 

Meetings  can  be  held  at  different  SEPG  sites  on  a  rotating  basis. 
Thus  the  host  site  and  others  in  close  proximity  may  have  more  than 
one  representative  attend  the  meetings.  Remote  sites  would  be  rep¬ 
resented  by  as  many  SEPG  members  that  the  site  could  afford  to 
send,  but  at  least  one  member,  preferably  the  SEPG  leader  should  at¬ 
tend  each  meeting. 

The  chair  of  the  SPIAC  is  elected  for  a  term  of  one  to  two  years.  The 
chair  is  responsible  for  the  agenda  and  for  coordinating  the  meeting 
activities,  schedule,  location,  and  so  forth.  The  site  hosting  the  meet¬ 
ing  is  usually  responsible  for  the  local  arrangements,  meeting  min¬ 
utes,  and  other  activities  necessary  to  facilitate  the  meeting. 

Tasks  Activities  of  the  SPIAC  include 

Hold  regularly  scheduled  meetings  (quarterly). 

•  Share  lessons  learned  with  other  SEPGs. 

Share  solutions  developed  with  other  SEPGs. 

•  Establish  common  position  on  critical  SPI  issues. 

•  Advise  management  on  global  SPI  matters. 

•  Identify  benefits  of  SPI  implementations. 

•  Maximize  the  use  of  SPI  resources  across  the  organization. 
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B.5  The  Executive  Council  (EC) 


Objectives  In  a  very  large  organization  that  has  many  divisions  scattered  geo¬ 

graphically  addressing  SPI  issues  independent  of  each  other,  man¬ 
agement  oversight  is  required.  The  executive  council  (EC)  serves 
this  purpose,  monitoring  and  evaluating  these  efforts  from  the  point 
of  view  of  the  total  organization. 

Purpose  The  EC  is  concerned  with  how  the  overall  improvement  efforts  tie 

in  with  the  vision  and  mission  that  the  organization  has  set  for  itself. 
Typically  the  EC  reviews  the  SPI  and  other  process  improvement  ef¬ 
forts  with  knowledge  of  the  corporation’s  future  directions  and 
guides  the  SPI  program  to  support  that  vision. 


The  EC  wants  to  ensure  that  the  overall  improvement  efforts,  includ¬ 
ing  SPI,  are  proceeding  in  a  direction  to  support  the  corporate  vision. 
To  support  its  direction  for  the  organization,  the  council  may  elect 
to  communicate  certain  broad  improvement  strategies  down  the  in¬ 
frastructure  chain  of  command  to  guide  the  improvement  efforts. 
This  broad  guidance,  based  on  strategic  opportunities,  becomes 
more  focused  moving  down  the  SPI  infrastructure.  The  divisions  or 
individual  business  units  can  enhance  and  add  focus  to  the  guidance 
from  the  EC  based  on  the  product  produced  and  market  opportuni¬ 
ties  in  their  business  environments. 

Membership  on  the  EC  is  kept  very  small.  There  are  no  more  than 
three  to  five  members  who  are  the  organization’s  most  senior  man¬ 
agement. 

Meetings  should  be  held  semi-annually.  At  the  meetings,  members 
of  the  EC  review  and  discuss  the  progress  of  the  SPI  programs. 
Changes  in  direction  or  focus  should  be  communicated  to  the  infra¬ 
structure. 
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Tasks 


Some  of  the  activities  performed  by  an  executive  council  include 

•  Hold  meetings  as  necessary  (semi-annually). 

•  Evaluate  progress  of  SPI  activities  against  defined  criteria. 
Review  SPI  activities  against  business  needs. 
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Purpose  A  charter  is  an  important  document  in  a  software  process  improve¬ 

ment  (SPI)  program.  A  charter  serves  as  an  agreement  or  contract 
between  two  parties.  On  one  hand,  the  charter  makes  explicit  the  au¬ 
thority  and  responsibility  of  the  entity  being  chartered  and  defines 
the  scope  and  mission.  On  the  other  hand  the  charter  conveys  com¬ 
mitment  from  and  implied  support  by  the  chartering  entity. 


The  first  part  of  this  appendix  contains  examples  of  actual  charters 
that  are  in  use  by  organizations  that  are  pursuing  software  process 
improvement. 

The  second  part  of  the  appendix  contains  templates  that  can  be  used 
in  the  planning  activities.  There  are  templates  for  a  strategic  action 
plan  used  by  the  organization  in  planning  its  SPI  activities 
(page  184),  a  template  for  a  tactical  action  plan  used  by  TWGs 
(page  188),  and  a  template  for  an  installation  plan  used  to  install  an 
improvement  (page  190). 

It  should  be  remembered  that  these  are  only  samples  and  sugges¬ 
tions.  What  works  in  some  organizations  may  not  work  in  others. 
Readers  should  tailor  these  instruments  to  fit  their  organizations. 
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C.1  Management  Steering  Group  Charter 


Generalized  Research  Company  -  Electronics  Group 
Research,  Development,  and  Engineering  Center 
Software  Engineering  Division 
Cooperstown,  New  York 
Management  Steering  Group  (MSG)  Charter 
14  November  1991 


1.  PURPOSE:  The  purpose  of  this  Charter  is  to: 

•  Establish  the  GRC-EG  Software  Engineering  Division  (SED)  MSG  for 
Software  Process  Improvement. 

•  Define  the  mission,  responsibilities,  membership,  and  conduct  of  operations 
for  the  MSG. 

2.  SCOPE:  This  Charter  applies  to  all  organizations  and  personnel,  including  sub¬ 
contract  personnel,  located  at  the  Electronics  Group,  Cooperstown,  New  York. 

3.  AUTHORITY:  Director,  Software  Engineering 

4.  MISSION:  To  support  the  operation  of  the  Software  Engineering  Process  Group  and 
the  execution  of  the  approved  Action  Plan  for  software  process  improvement  within 
SED.  Utilizing  the  Software  Engineering  Institute's  (SEI)  Software  Process  Assessment 
(SPA)  methodology,  SED's  goals  and  objectives  are  to  identify  key  areas  for  process 
improvement  and  to  propose  a  framework  for  improvement  actions  consistent  with  the 
SED  vision  for  software  process  improvement.  It  will  also  include  oversight  support  of 
Total  Quality  Management  (TQM)  initiatives. 

5.  MANAGEMENT  STEERING  GROUP  RESPONSIBILITIES: 

•  To  approve  the  establishment  of  Technical  Working  Groups  (TWGs). 

To  approve  and  support  the  membership  of  TWGs. 

To  provide  guidance  to  TWGs  work  in  progress. 

•  To  support  the  implementation  of  approved  recommendations. 

•  To  Approve  TWG  initiatives  and  recommendations. 

To  tenninate  TWGs,  as  appropriate. 
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6.  MEMBERSHIP: 


Director,  GRC-SED  (Chair) 

Director,  Systems  Support 
Manager,  Applications  Development 
Manager,  Customer  Support  Center 
Manager,  Systems  Software  Development 


Assistant  Director,  GRC-SED 
Director,  Operation  and  Engineering 
Manager,  Network  Development 
Manager,  Quality  Assurance 
Manager,  Documentation  Development 


7.  ASSOCIATE  MEMBERSHIP:  Manager,  SEPG 

8.  CONDUCT  OF  OPERATIONS: 


•  The  Management  Steering  Group  will  meet  bi-monthly  or  as  called  for  by 
the  Management  Steering  Group  Chairman. 

•  Meetings  will  have  a  fonnal  agenda  distributed  at  least  three  days  prior  to 
the  meeting  and  all  meetings  will  be  documented. 

9.  TERMINATION:  Not  applicable. 


Daniel  A.  Gibson 

Director,  Software  Engineering  Division 
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C.2  Software  Engineering  Process  Group  Charter 


General  Research  Company  -  Electronics  Group 
Research,  Development,  and  Engineering  Center 
Software  Engineering  Division 
Cooperstown,  New  York 

Software  Engineering  Process  Group  (SEPG)  Charter 

12  December  1991 

1.  PURPOSE:  The  purpose  of  this  Charter  is  to  authorize  and  approve: 

a.  The  establishment  of  a  Software  Engineering  Process  Group 

b.  Membership 

c.  Conduct  of  operations 

2.  SCOPE:  This  Charter  applies  to  all  organizations  and  personnel  located  at  the 
Electronics  Group,  Software  Engineering  Division,  Cooperstown,  New  York. 

3.  AUTHORITY:  Director,  Software  Engineering 

4.  MISSION: 

a.  To  manage  the  Electronics  Groups  process  improvement  program. 

b.  To  organize  and  initiate  the  prioritized  actions  in  the  approved  Electronics 
Groups  Action  Plan. 

c.  To  facilitate  and  monitor  the  development  and  implementation  of  process 
improvements. 

d.  To  create  an  atmosphere  to  foster  change. 

5.  RESPONSIBILITIES: 

a.  Oversee  process  improvement  activities  and  report  progress. 

b.  Serve  as  Electronics  Group's  Change  Agent. 

c.  Lead  Electronics  Group  Software  Process  Assessments  (SPAs). 

d.  Facilitate  action  planning. 
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e.  Oversee  Electronics  Group's  TQM  Program. 

f.  Facilitate  and  advise  Technical  Working  Groups  (TWGs). 

g.  Provide  for  training  necessary  to  promote  TQM  and  process  improvement  to 
maintain  an  atmosphere  receptive  to  change. 

h.  Serve  as  focal  point  for  coordination  of  Electronics  Group  process 
improvement  activities  with  SEI,  Corporate  headquarters,  and  sub-contractor 
organizations. 

i.  Oversee  activities  of  all  Electronics  Group  SEPGs. 

6.  MEMBERSHIP:  The  Software  Engineering  Process  Group  membership  consists  of 
Core  Members,  and  Review  Members.  Membership  will  be  re-established  during  the 
planning  phase  for  the  next  Electronics  Group  SPA  effort.  The  identification  and 
responsibilities  of  Software  Engineering  Process  Group  members  are  defined  below: 

a.  Core  Members  will  participate  100  percent  of  their  time  excluding  leave  and 
required  administrative  duties.  The  Core  Members  shall  perfonn  the 
majority  of  overseeing  implementation  of  the  Action  Plan  toward  process 
improvement.  The  Core  Members  are: 

David  Rimson,  SEPG  Manager 

John  Sibling,  SEPG  Member 

Renee  Doyle,  SEPG  Member 

Barbara  Cott,  SEPG  Member 

Janet  Dempsey,  SEPG  Administrative 

b.  Review  Members  will  contribute  up  to  10  percent  of  their  time.  The  Review 
Members  are  a  representative  group  of  managers  and  practitioners  who  meet 
as  required  to  provide  insight,  additional  data,  and  consensus  on  the 
implementation  of  the  Action  Plan.  Review  Members  will  also  act  as  a  focal 
point  to  identify  experts  within  their  organization  on  particular  topics. The 
Review  Members  are: 

Systems  Support,  C.  Royce 

Applications  Development,  T.  Royce/J.  Hasek 

Customer  Support,  R.  Davidson 

Systems  Software,  P.  Thomas 

Operations  &  Engineering,  R.  Fichter,  D.  Jockel 

Network  Development,  T.  Dzik 
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Quality  Assurance,  J.  Potoczniak 
Publications,  M.  Burkitt 

7.  CONDUCT  OF  OPERATIONS: 

a.  The  SEPG  will  report  to  and  receive  guidance  from  the  Assistant  Director, 
Software  Engineering  Division,  Electronics  Group. 

b.  SEPG  will  hold  regular  meetings  as  required. 

c.  The  SEPG  will  keep  the  Division  Director,  Assistant  Director,  Division 
management,  and  Sub-contractor  management  infonned  via  regular  reports 
through  the  Assistant  Director. 

d.  The  SEPG  will  facilitate  TWG  Meetings. 

e.  The  SEPG  will  present  periodic  status  reviews  and  conceptual  briefings  to  the 
Management  Steering  Group  (MSG). 

f.  The  SEPG  Chair  will  be  an  associate  member  of  the  MSG. 

8.  EXPECTED  PRODUCTS: 

a.  Documented  processes  and  procedures  on  the  execution  of  the  Division's 
software  processes 

b.  Status  review  briefings  to  MSG 

c.  TWG  Status  Reports 

d.  Newsletter  input  to  Software  Engineering  News 

e.  Monthly  update  newsletter  on  electronic  mail 

f.  Presentations  to  Division  workforce  on  process  improvement 

g.  Process  improvement  promotional  materials 

h.  Process  improvement  metrics  reports 

9.  MILESTONE  PLAN:  To  be  presented  and  approved  by  the  MSG  at  the  first 
meeting. 

10.  TERMINATION:  The  SEPG  will  function  indefinitely. 


Daniel  A.  Gibson 

Director,  Software  Engineering  Division 
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C.3  Software  Process  Improvement  Advisory 

Committee  Charter 


Corporate  Accounting  Services  (CAS) 

Software  Process  Improvement  (SPI) 

Advisory  Committee  (AC) 

Charter 

1 .  PURPOSE.  The  purpose  of  the  CAS  SPI  Advisory  Committee  (SPIAC)  is  to  support 
the  long-term  process  improvement  activities  of  the  SEPGs  by  facilitating  interaction 
among  the  CAS  SEPGs  which  will  promote  infonnation  sharing  and  provide  a 
mechanism  for  the  SEPGs  to  address  common  problems. 

2.  SCOPE.  This  Charter  applies  to  the  membership  of  the  SPIAC  and  joint  activities  of 
the  individual  SEPGs  established  by  CAS.  The  scope  of  this  charter  is  to: 

a.  Delineate  the  mission  of  the  SPIAC 

b.  Define  the  concept  of  operations 

c.  Define  the  membership 

3.  MISSION. 

a.  Provide  a  forum  for  sharing  of  process  improvement  issues,  infonnation, 
successful  practices,  and  lessons  learned  among  the  CAS  SEPGs. 

b.  Advise  CAS  management  on  process  improvement  matters. 

c.  Establish  joint  positions  on  critical  software  engineering  process 
improvement  issues. 

d.  Identify  benefits  of  and  requirements  for  process  improvement 
implementation  across  the  SEPGs. 

e.  Maintain  software  engineering  process  definitions,  improvement 
methodologies,  improvement  tools,  and  process  improvement  metrics  that 
are  suitable  for  implementation  across  the  centers/sites. 

f.  Maximize  the  sharing  of  available  Software  Engineering  Institute  (SEI)  and 
other  process  improvement  resources  across  CAS  SEPGs  to  include 
coordinating  common  education  on  process  improvement. 

g.  Participate  with  government  organizations,  industry,  academia,  and  Software 
Process  Improvement  Network  (SPIN)  process  improvement  efforts. 
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4.  CONCEPT  OF  OPERATIONS. 

a.  The  SPIAC  will  conduct  its  activities  in  an  atmosphere  of  non-attribution. 

b.  The  following  roles  will  be  established  for  the  functioning  of  the  SPIAC: 
facilitator,  member,  scribe,  minute  taker,  time  keeper,  host,  and  technical 
advisor.  The  specific  responsibilities  for  these  roles  will  be  agreed  to  by  the 
SPIAC. 

c.  The  SPIAC  will  meet  quarterly,  and  will  be  scheduled,  if  possible,  to  coincide 
with  the  annual  SEPG  National  Meeting  and  the  annual  Software 
Engineering  Symposium.  SPIAC  meetings  will  coincide  with  CAS  Directors' 
meeting  as  necessary. 

d.  Site  and  agenda  for  each  meeting  will  be  detennined  by  mutual  consent  of  the 
SPIAC. 

e.  SPIAC  members  will  execute  tasks  as  agreed  upon  during  meetings. 

f.  SPIAC  can  recommend  supplemental  PATs/working  groups  for  software 
process  improvement. 

g.  Reports,  recommendations,  and  minutes  will  be  submitted  to  the  CAS 
Directors. 

h.  All  SEPG  members  are  welcome  to  attend  all  meetings.  One  SEPG  member 
will  be  designated  to  represent  each  site,  with  all  attendees  having  equal 
voice  discussions. 

5.  MEMBERSHIP. 

a.  The  recognized  CAS  SEPG  sites  are  as  follows: 

CAS  West,  San  Diego 
CAS  South,  Atlanta 
CAS  East,  Philadelphia 
CAS  International,  New  York 

b.  Membership  is  open  to  all  SEPG  members  from  these  sites. 

c.  The  Software  Engineering  Institute  is  invited  to  attend  SPIAC  meetings  in  a 
technical  advisory  role. 

6.  REVISION.  This  charter  will  be  reviewed  and  revised  as  deemed  necessary  by  the 

SPIAC  and  its  sponsors. 

7.  TERMINATION.  The  SPIAC  will  function  continuously  until  such  time  as  it  is  no 

longer  needed. 

8.  SPONSORS. 


182 


CMU/SEI-95-UG-001 


C.O  Charters  and  Templates 

C.3  Software  Process  Improvement  Advisory  Committee  Charter 


David  F.  Wilson 
Director,  CAS  West 


William  Johnson 
Director,  CAS  South 


James  W.  Davison 
Director,  CAS  East 


Robert  Smithwell 
Director,  CAS  International 
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Purpose  This  plan  provides  an  introduction  to  the  SPI  program  with  context 

and  background  for  how  the  organization  has  arrived  at  this  point. 

•  It  is  based  on  baseline  findings  and  recommendations  report. 

•  It  describes  the  motivation  and  direction  for  addressing  the 
findings  within  a  SPI  program. 

•  It  defines  long-range  and  near-tenn  goals. 

Contents  The  suggested  sections  in  the  SPI  strategic  action  plan  are  identified 

in  the  left  column  and  comments  are  in  the  right  column. 

1 .  Overview  Provide  context  and  background  on  how  the  organization  arrived  at 

this  point. 

2.  Executive  Explain  how  this  action  plan  will  integrate  all  software  process  im- 

Summary  provement  activities  at  this  center. 

•  Explain  how  the  current  improvement  efforts  will  be  linked  to 
recommendations  from  the  assessment  and  how  those  efforts 
and  future  efforts  will  be  integrated,  coordinated,  and  tied  to  the 
vision. 

•  Explain  also  that  this  strategic  action  plan  will  provide  answers 
to  the  following  questions:  {Note:  Examine  these  questions.  If 
they  are  not  the  right  ones  for  your  organization,  change  them. 
Make  sure  that  there  are  sections  within  the  plan  that  address 
each  question,  however.) 

What  are  our  goals  for  the  SPI  program? 

What  is  our  motivation  to  improve? 

What  assumptions  are  we  making? 

Who  are  the  players? 

How  will  we  measure  successes? 
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3.  Process 
Improvement 
Goals 


4.  Objectives 


5.  Assumptions  and 
Risks 


How  will  we  continue  to  improve? 

•  Define  the  long-term  (3-5  years)  and  short-term  (1  year  or  prod¬ 
uct  cycle)  goals  for  the  improvement  program. 


•  List  the  strategic  goals  that  have  been  developed  as  a  result  of  the 
assessment  (e.g.,  productivity,  quality,  risk,  maturity  goals  from 
the  action  plan  structure  materials). 

•  List  the  strategic  goals  that  have  developed  from  the  vision  or 
other  sources.  (Note:  Keep  goals  few,  concise,  unambiguous, 
and  measurable.) 

First,  describe  why  this  SPI  program  is  important  and  why  anyone 
should  care  and  want  to  do  anything. 

List  the  principal  motivations  (e.g.,  increase  competitiveness, 
avoid  consolidation  or  closure)  that  will  drive  the  SPI  program. 

State  the  objectives  (e.g.,  to  improve  the  quality  and  productivity 
of  the  organization's  products,  services,  and  resources)  and  the 
consequences  of  maintaining  status  quo. 

Second,  define  the  guiding  principles  to  be  followed  during  the  SPI 
program  to  achieve  the  goals  and  objectives  (e.g.,  using  the  SPI  pro¬ 
gram  to  model  higher  maturity  behavior.  Look  at  the  next  maturity 
level  and  determine  how  those  key  process  areas  can  be  applied  and 
used  in  the  SPI  program  itself.) 

List  critical  assumptions  (e.g.,  sponsorship,  work  load,  resource 
availability)  and  describe  how  each  affects  the  plan. 

•  Discuss  the  risks  implied  by  these  assumptions. 

•  Identify  the  barriers,  including  the  non-technological  barriers,  to 
the  improvement  program  and  describe  the  strategies  to  reduce 
those  barriers.  (Note:  If  using  the  Managing  Technological 
Change  implementation  plan,  tie  it  in  here.) 
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6.  Organization  for 
Process 
Improvement 


7.  Responsibility 
Matrix 


8.  Criteria  for 
Success 


Define  and  describe  the  infrastructure  that  is  in  place  or  being 
created  to  support  the  improvement  program. 

Describe  the  organizational  entities  (e.g.,  MSG,  SEPG,  etc.)  cre¬ 
ated  to  support  process  improvement  in  terms  of  their  composi¬ 
tion,  roles,  responsibilities,  and  interfaces.  Reference  the  char¬ 
ters  for  these  groups  and  attach  those  charters  to  Section  9,  Im¬ 
provement  Agenda. 

Identify  the  sponsor  and  what  current  resources  are  committed. 
{Note:  this  is  summarized  from  the  resources  identified  in  Sec¬ 
tion  9.) 

Describe  which  group  is  responsible  for  what  throughout  the  SPI 
program 

List  the  SEPG  coordinating  activities  with  the  MSG  and  TWGs. 

Describe  which  group  is  responsible  for  what  throughout  the  SPI 
program. 

Describe  how  the  goals  from  Section  3  (Process  Improvement 
Goals)  will  be  measured  and  how  the  organization  will  recog¬ 
nize  success  in  achieving  those  goals. 

Describe  how  improvement  activities  will  be  measured  and  eval¬ 
uated  at  both  the  organizational  and  project  levels. 


9.  Improvement 
Agenda 


Provide  a  high-level  description  of  all  current  improvement 
efforts  in  terms  of  what  they  are  doing,  what  resources  are 
currently  committed  to  the  activity,  and  what  resources  are 
required  to  complete  the  activity. 

Describe  how  the  above  existing  activities  map  to  the  recom¬ 
mendations  from  the  assessment.  Identify  any  gaps,  partial  or 
otherwise,  between  the  recommendations  and  the  current  im¬ 
provement  activities. 

Provide  a  high-level  description  of  all  additional  improvement 
activities  that  will  be  needed  to  completely  address  all  of  the  rec¬ 
ommendations  and  achieve  the  goals  and  objectives  of  this  ac¬ 
tion  plan.  This  description  should  be  expressed  in  tenns  of  what 


This  section  provides  the  what  of  the  action  plan.  The  efforts  are  de¬ 
scribed  at  a  high  level,  resource  requirements  are  identified,  and  the 
relationships  between  each  major  activity  are  described  so  that  the 
reader  can  see  how  these  different  activities  are  integrated. 
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each  activity  will  accomplish  and  what  resources  are  required  to 
accomplish  the  activity. 

Define  how  activities  will  be  prioritized  and  what  the  priority 
and  selection  criteria  will  be. 

Identify  how  improvement  projects  will  be  selected  to  partici¬ 
pate  in  the  SPI  program. 
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C.5  Tactical  Action  Plan 

Purpose  This  plan  identifies  the  activities,  schedules,  and  deliverables  of  a 

TWG. 


Contents 


1.  Introduction/ 
Overview 


2.  Objectives/ 
Charter 


3.  Detailed 
Description 


4.  Resources 


The  plan  also  discusses  resource  requirements;  interfaces  and  de¬ 
pendencies  with  other  groups;  assumptions,  risks,  and  risk  mitiga¬ 
tion;  and  schedules  and  milestones. 

•  Specify  the  charter  and  scope  the  effort  of  the  TWG. 

Guide  the  TWG  efforts. 

The  suggested  sections  in  the  tactical  action  plan  are  identified  in  the 
left  column  and  comments  are  in  the  right  column. 

•  Identify  the  recommendation  that  this  plan  will  support. 

•  Provide  an  overview  of  what  must  be  accomplished. 

Describe  the  objectives  and  purpose  of  this  working  group. 
{Note:  If  this  infonnation  already  exists  in  the  fonn  of  a  charter, 
that  document  should  be  appended  to  the  action  plan.) 

Describe  the  scope  of  the  working  group's  efforts. 

•  Provide  an  accurate  and  concise  description  of  the  task. 

•  Include  a  definition  of  what  the  task  is  and  a  list  of  the  major  ac¬ 
tivities  and  artifacts  associated  with  it. 

Describe  resources  required  for  this  task,  including  personnel,  mon¬ 
ey,  computer  resources,  etc.  Also  describe  who  is  responsible  for 
each  task. 
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5.  Interfaces/ 
Dependencies 

6.  Work  Breakdown 
Structure  (WBS) 

7.  Schedule 

8.  Risks 

9.  Status/Monitoring 


Each  working  group  has  an  interface  with  other  groups.  Define  and 
document  these  interfaces  in  this  section. 

Break  the  overall  task  into  small,  manageable  pieces  that  can  be  used 
as  the  basis  for  planning,  identifying  milestones,  reporting,  and  con¬ 
trol. 

•  Describe  when  each  of  the  task  elements  described  in  the  WBS 
are  to  be  completed.  Use  Gantt  or  PERT  charts. 

•  Key  accomplishments  should  be  made  into  milestones  and 
tracked  against  original  estimates. 

Provide  a  basis  for  risk  management  and  contingency  planning. 

Describe  how  status  will  be  reported.  (Note:  Completed  status 
reports  should  be  appended  to  the  tactical  action  plan  to  maintain 
a  history  of  all  activity.) 

Discuss  how  progress  will  be  monitored  (comparisons  of  actual 
progress  against  proposed  schedules). 

Discuss  how  significant  schedule  deviations  or  changes  will  be 
handled. 
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C.6  Installation  Plan 


Purpose  This  plan  will  define  the  steps  necessary  to  install  an  improvement 

into  a  subunit  of  the  organization.  The  plan  will  contain  the  objective 
and  purpose  of  the  improvement,  a  WBS  of  the  activities,  schedules, 
resource  requirements,  and  criteria  for  success. 

Contents  The  suggested  sections  in  the  installation  plan  are  identified  in  the 

left  column  and  comments  are  in  the  right  column. 

1.  Introduction/  •  Identify  the  technology  to  be  installed  that  this  plan  will  support. 

Overview 


•  Provide  an  overview  of  what  must  be  accomplished. 

2.  Goals,  Objectives  Describe  what  will  (should)  be  accomplished,  why  it  is  needed,  and 

and  Purpose  what  kinds  of  projects  or  functional  areas  it  applies  to.  (Note:  goals 

should  be  measurable.) 

3.  T  echnology  •  Provide  an  accurate  and  concise  description  of  the  technology. 

Description 

•  Include  a  definition  of  what  the  technology  is  and  a  list  of  the 
major  activities  and  artifacts  associated  with  using  that  technol¬ 
ogy- 

4.  Tailoring  •  Provide  guidelines  on  how  and  when  to  tailor  this  technology 

and  this  installation  plan. 

•  Define  the  mandatory  requirements  and  the  optional  compo¬ 
nents  or  requirements. 

•  Define  options  in  terms  of  types  of  projects,  types  of  functional 
areas,  etc. 

5.  Education  and  •  Describe  what  training  (formal  or  informal)  and  education  is  (a) 

T  ra  i  n  i  n  g  required  and  (b)  desirable  for  installation  and  use  of  this  technol¬ 

ogy- 
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Procedures 

7.  Work  Breakdown 
Structure 


8.  Schedule 


9.  Resources 

10.  Interfaces/ 
Dependencies 

1 1  .Risks 

12. Status/Monitoring 


•  Define  where  and  when  this  training  or  education  is  available, 
costs,  lead  times  for  reserving  training  seats,  the  process  to  be 
followed  to  request  the  training,  and  from  whom  it  is  requested. 

Describe  how  the  project  or  functional  area  will  evaluate  their  instal¬ 
lation  and  use.  How  will  they  know  they  have  it  right? 

Break  the  installation  into  small,  manageable  pieces  that  can  be  used 
as  the  basis  for  planning,  reporting,  and  control.  Define  entry  condi¬ 
tions  and  inputs,  task  descriptions,  validation  criteria,  and  exit  con¬ 
ditions  and  outputs  for  each  task. 

•  Describe  when  each  of  the  task  elements  described  in  the  WBS 
are  to  be  completed.  Use  Gantt  or  PERT  charts. 

•  Make  key  accomplishments  into  milestones  and  track  against 
original  estimates. 

Describe  resources  required  for  this  task,  including  personnel,  mon¬ 
ey,  computer  resources,  etc.  Also  describe  who  is  responsible  for 
each  task. 

Each  working  group  has  an  interface  with  other  groups. 

Defined  and  document  these  interfaces  in  this  section. 

Provide  a  basis  for  risk  management  and  contingency  planning. 

Describe  how  status  will  be  reported.  (Note:  Completed  status 
reports  should  be  appended  to  the  plan  to  maintain  a  history  of 
all  activity.) 

Discuss  how  progress  will  be  monitored  (comparisons  of  actual 
progress  against  proposed  schedules). 

Discuss  how  significant  schedule  deviations  or  changes  will  be 
handled. 
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D.O  Establish  Organization  Process 

Maturity  Baseline 


Purpose  There  are  many  different  ways  to  conduct  an  internal  assessment  of 

an  organization’s  strengths  and  weaknesses.  Organizations  have 
used  a  variety  of  assessment  methods  in  the  past,  and  new  variations 
are  constantly  being  developed.  A  variety  of  assessment  methods  is 
needed  because  of  the  differences  between  organizations:  size,  pre¬ 
vious  assessment  activity,  funds  available,  and  so  on.  Rather  than 
describe  just  one  method,  this  appendix  describes  a  generic  series  of 
assessment  activities  based  on  the  Software  Engineering  Institute 
(SEI)  software  process  assessment  (SPA)  methods.  The  intent  is  to 
provide  an  understanding  of  the  types  and  kind  of  activities  involved 
in  conducting  an  assessment.  The  software  engineering  process 
group  (SEPG)  should  determine  the  type  of  assessment  it  wishes  to 
conduct  and  get  training  on  that  method. 


The  organization  process  maturity  baseline  establishes  the  software 
process  maturity  level  of  the  organization  and  identifies  key  areas 
for  process  improvement.  The  SEPG  usually  plans,  organizes,  and 
leads  its  organization’s  assessment.  Following  the  assessment,  the 
SEPG  formally  documents  the  results  of  the  assessment  in  a  final  re¬ 
port.  The  assessment  team  typically  consists  of  the  SEPG  and  other 
assessment  team  members,  drawn  either  from  outside  the  assess¬ 
ment  site  or  from  within  the  assessed  organization. 

A  key  step  of  a  capability  maturity  model  (CMM)-based  SPI  pro¬ 
gram  is  identifying  where  the  organization  fits  on  the  maturity  mod¬ 
el.  These  activities  identify  a  set  of  key  issues  that,  if  addressed,  can 
launch  the  organization  on  the  road  to  improvement.  This  phase  can 
be  considered  successful  if  two  goals  are  met: 

1 .  A  reasonable  set  of  issues  is  identified  and  agreed  upon  by  all  in¬ 
volved,  and  recommendations  are  developed  to  move  the  orga¬ 
nization  down  the  road  to  improvement. 
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Objectives 


Entry  Criteria 


Tasks 


D.1 

Prepare  for 
Assessment 


Figure  F-1: 


2.  The  organization  becomes  excited  and  interested  in  making 
changes  at  all  levels,  from  the  lowest  practitioner  to  the  senior 
manager.  This  phase  contains  some  of  the  most  stressing  mo¬ 
ments  for  the  SEPG,  both  internally  and  in  its  relationship  to  se¬ 
nior  management.  It  is  this  “cauldron”  that  can  either  forge  the 
SEPG  into  a  high-performing  team  or  can  break  the  team.  The 
latter,  if  it  occurs,  usually  leads  to  dissolution  of  the  SPI  pro¬ 
gram. 

•  Prepare  the  team  and  organization  for  conducting  the  assess¬ 
ment. 

•  Gather  infonnation  on  the  organization’s  software  process  matu¬ 
rity  level,  identify  key  process  issues  facing  the  organization, 
and  start  to  develop  a  set  of  priorities  for  improvement. 

•  Generate  a  document  detailing  all  results  of  the  assessment,  in¬ 
cluding  the  findings  that  were  presented  during  the  final  findings 
briefing  at  the  on-site  period  and  recommendations  for  address¬ 
ing  those  findings. 

•  Increase  involvement  and  commitment  throughout  the  organiza¬ 
tion. 

•  Identify  barriers  to  change  within  the  organization. 

•  Continue  team  building  for  the  SEPG. 

•  The  baseline  method  for  software  process  maturity  assessment 
has  been  selected. 

•  A  team  has  been  established  and  resources  committed  to  conduct 
the  SPA. 

See  Figure  F-1  on  page  194  for  a  pictorial  representation  of  the 

tasks. 
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The  subtasks  for  D.O,  Establish  Organization  Process  Maturity 
Baseline,  are 


Subtask 

Page 

Number 

D.1 :  Prepare  for  Assessment 

196 

D.2:  Conduct  Assessment 

199 

D.3:  Develop  Baseline  Findings  and  Recommendations  Report 

201 
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D.1  Prepare  for  Assessment 


Purpose  The  purpose  of  this  activity  is  to  lay  the  groundwork  for  a  smooth 

and  successful  assessment.  A  critical  initial  activity  is  to  establish 
the  scope  of  the  assessment  by  identifying  the  parts  of  the  organiza¬ 
tion  that  will  be  assessed  and  that  will  participate.  This  is  usually  fol¬ 
lowed  by  selecting  a  team  that  represents  those  parts  of  the  organi¬ 
zation  to  be  assessed  and  training  that  team  in  the  specific  assess¬ 
ment  method  chosen.  Key  assessment  dates  must  be  negotiated  and 
finalized,  such  as  dates  for 

•  Initial  data-gathering  and  analysis. 

•  Detailed  interviewing  and  definition  of  issues. 

•  Development  of  recommendations. 

•  Delivery  of  final  report. 

Then  the  participants,  particularly  the  projects  and  functional  area 
representatives,  must  be  selected  and  briefed  on  their  roles  and  ac¬ 
tivities.  The  bulk  of  the  organization  to  be  assessed  must  understand 
what  will  happen  and  how  it  relates  to  the  SPI  program.  Typically 
this  infonnation  is  conveyed  through  a  series  of  briefings.  Detailed 
plans  should  be  developed  for  all  steps  of  the  pre-assessment,  assess¬ 
ment,  and  post-assessment  periods. 

Objectives  •  Get  a  team  trained  in  the  SPA  method  selected. 

•  Determine  the  scope  of  the  assessment  and  select  projects  and 
functional  area  representatives  to  participate  in  the  assessment. 

•  Make  the  bulk  of  the  organization  to  be  assessed  aware  of  what 
an  assessment  is,  how  it  fits  into  the  overall  SPI  program,  and 
what  will  happen  in  terms  of  activities  and  outputs  during  and 
immediately  after  the  assessment. 

•  Finalize  dates  for  the  key  assessment  events  and  develop  de¬ 
tailed  plans  and  schedules  for  all  activities. 
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Entry  Criteria 
Education/Training 


Communication 


Exit  Criteria 


Prepare  all  logistics,  materials  to  be  used,  files,  templates,  brief¬ 
ings,  etc.,  and  ensure  that  all  tools,  equipment,  and  materials  are 
ready  and  in  place. 

A  team  has  been  established  and  resources  committed  to  conduct  the 
SPA. 

A  training  session  for  an  assessment  team  occurs  during  this  phase. 
The  purpose  is  to  train  a  team  in  the  specific  mechanics  and  skill  re¬ 
quirements  of  the  selected  assessment  method  as  well  as  to  provide 
any  required  background  information. 

Two  groups  have  responsibility  for  most  communications  during 
this  period:  the  management  steering  group  (MSG)  and  the  SEPG. 

The  MSG  should  publicly  sponsor  and  support  the  assessment,  pref¬ 
erably  through  individual  staff  meetings  and  at  group  briefings. 

The  SEPG  will  conduct  informational  briefings  for  the  organization 
as  a  whole  on  what  the  assessment  is,  how  it  relates  to  the  SPI  pro¬ 
gram,  and  what  will  be  happening.  This  is  typically  done  through 
briefings  to  sections  of  the  organization,  with  most  of  the  people  in 
that  section  attending  along  with  the  section’s  manager. 

The  SEPG  should  also  brief  the  selected  participants  on  their  roles, 
responsibilities,  detailed  schedules,  and  the  overall  assessment  pro¬ 
cess,  concentrating  on  how  the  participants’  infonnation  is  to  be 
used. 

All  preparations  are  completed  for  the  assessment.  Invitations  have 
been  issued,  functional  area  representatives  (FARs)  and 

project  leaders  are  briefed,  everything  is  scheduled  and  ready  to  go, 
and  a  complete  dry  run  of  the  process  has  been  satisfactorily  com¬ 
pleted. 
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Tasks 


The  sub  tasks  for  D.  1,  Prepare  for  Assessment,  are 

•  Determine  scope  of  the  assessment. 

•  Select  and  train  team  in  the  assessment  method  chosen. 

Set  expectations. 

•  Determine  assessment  participants. 

•  Finalize  assessment  dates,  plans,  and  schedules. 

•  Prepare  and  test  logistics  for  the  assessment. 

•  Hold  dry  run  or  team  walkthrough  of  the  assessment  process. 

•  Plan  development  activities  for  final  report. 
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D.2  Conduct  Assessment 


Purpose  The  purpose  of  this  activity  is  to  conduct  the  assessment.  This  typi¬ 

cally  starts  with  an  opening  participants’  briefing  for  all  assessment 
participants,  where  the  events,  objectives,  and  schedules  are  re¬ 
viewed.  The  maturity  questionnaire  is  filled  out  by  the  selected  par¬ 
ticipants,  and  then  the  assessment  team  analyzes  the  responses  to  the 
questionnaire.  The  assessment  team  then  prepares  questions  and  ar¬ 
eas  to  probe  further  for  the  detailed  interviewing  and  issue  definition 
period  and  decides  what  supporting  material  it  will  need  to  examine. 
The  team  finalizes  plans  and  logistics  for  this  follow-up  period  and 
then  begins  it. 

Objectives  •  Gather  infonnation  on  the  organization’s  software  process  ma¬ 

turity  level,  identify  key  process  issues  facing  the  organization, 
and  start  to  develop  priorities  for  improvement. 


•  Build  consensus  on  the  issues  facing  the  organization  and  devel¬ 
op  excitement  and  enthusiasm  for  making  necessary  changes. 

•  Publicly  report  on  the  issues  facing  the  organization  and  the 
strengths  to  build  upon. 

Entry  Criteria  All  preparations  are  completed  for  the  assessment.  Invitations  have 

been  issued,  FARs  and  project  leaders  have  been  briefed,  and  every¬ 
thing  is  scheduled  and  ready  to  go. 

Communication  Five  groups  have  responsibility  for  most  communications  during 

this  period:  senior  management,  middle  management,  the  assess¬ 
ment  team,  project  leaders,  and  FARs. 

Senior  management  should  publicly  sponsor  and  support  the  assess¬ 
ment  process  and  ensure  that  their  line  managers  support  the  process 
as  well,  particularly  by  allocating  time  for  the  participants.  Senior 
management  also  should  emphasize  that  open  and  honest  responses 
are  desired  and  should  accept  and  acknowledge  the  findings. 

Middle  management  should  support  the  process  and  ensure  that  any 
of  their  people  who  are  participating  in  the  assessment  process  are 
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able  to  be  at  their  assigned  activities  on  time  and  without  interrup¬ 
tions. 

The  assessment  team  will  be  providing  information  to  the  partici¬ 
pants  on  the  process  and  detailed  schedules.  In  addition,  they  pro¬ 
vide  feedback  to  participants  and  formally  present  the  assessment  re¬ 
sults  to  the  organization. 

The  project  leaders  will  be  providing  information  about  their 
projects  and  giving  feedback  to  the  assessment  team  about  com¬ 
pleteness,  accuracy,  and  credibility  of  the  findings. 

The  FARs  will  be  providing  their  perspective  on  issues  that  get  in 
the  way  of  accomplishing  their  jobs.  They  will  also  identify 
strengths  and  provide  feedback  to  the  assessment  team  on  the  com¬ 
pleteness  and  accuracy  of  the  findings. 

Exit  Criteria  The  on-site  period  has  been  successfully  completed. 

Tasks  The  subtasks  for  D.2,  Conduct  Assessment,  are 

•  Brief  assessment  participants. 

•  Administer  maturity  questionnaires  and  gather  responses. 

•  Analyze  responses  and  determine  questions  to  be  asked  during 
interview  periods  as  well  as  areas  to  probe  in  more  depth. 

•  Finalize  plans  and  logistics. 

•  Finalize  preparation  of  supporting  materials  to  be  used  during 
the  interviewing  period. 

Conduct  detailed  interviews  and  hold  focus  group  discussions 
with  selected  participants. 

•  Identify  issues  and  rank  them. 

•  Gather  feedback  on  the  issues  identified  and  refine  them  as  nec¬ 
essary. 

•  Prepare  and  present  a  briefing  to  the  management  team  and  the 
organization  as  a  whole  on  the  strengths  and  issues  identified 
and  their  consequences. 
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D.3  Develop  Baseline  Findings  and 

Recommendations  Report 


Purpose  The  purpose  of  this  activity  is  to  document  the  findings  in  more  de¬ 

tail  than  was  presented  in  the  assessment  period  briefing  and  to  de¬ 
velop  recommendations  to  address  those  findings. 

Typically  the  recommendations  are  developed  through  a  series  of 
brainstorming  or  focus  group  sessions  held  with  practitioners,  mid¬ 
dle-level,  and  senior-level  managers.  The  participants  in  each  ses¬ 
sion  are  asked  to  brainstorm  recommendations  for  each  findings  cat¬ 
egory.  They  are  then  asked  to  identify  those  recommendations  that 
could  be  simply  and  easily  implemented  in  a  short  period  of  time. 
Volunteers  are  solicited  to  start  working  on  some  of  those  simple  im¬ 
provements. 

The  assessment  team  then  consolidates  the  recommendations  from 
all  the  sessions  and  creates  final  categories  and  descriptions  of  rec¬ 
ommendations.  The  findings  and  recommendations  are  combined 
into  a  report,  which  is  circulated  through  the  assessment  team,  the 
MSG,  and  other  selected  key  stakeholders  for  review  and  comment. 
The  revised  findings  and  recommendations  are  combined  with  the 
plans  for  the  action  planning  phase,  and  this  report  is  delivered, 
along  with  a  briefing,  to  senior  management. 

Objectives  •  Increase  commitment  of  different  levels  of  the  organization  by 

involving  practitioners  and  middle  and  senior  management  in 
the  process  of  developing  recommendations. 

•  Develop  recommendations  for  the  organization  to  address  the 
findings  identified  during  the  assessment  period. 

•  Identify  simple,  inexpensive  improvements  that  can  begin  im¬ 
mediately,  launch  those  efforts,  and  start  to  track  them. 

•  Submit  a  report  and  briefing  of  the  assessment  team’s  findings 
and  the  composite  organization’s  recommendations  to  senior 
management. 
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Entry  Criteria 
Communication 


Exit  Criteria 


•  Secure  senior  management  commitment  to  proceed  to  the  next 
phase,  action  planning. 

The  on-site  period  has  been  successfully  completed. 

Four  groups  have  responsibility  for  most  communications  during 
this  period:  the  MSG,  middle  management,  the  SEPG,  and  practitio¬ 
ners. 

The  MSG  should  publicly  sponsor  and  support  the  recommenda¬ 
tions  process  and  ensure  that  lower  level  managers  support  the  pro¬ 
cess  as  well,  particularly  by  allocating  time  for  the  participants.  Se¬ 
nior  management  also  should  provide  input  on  recommendations  in 
the  senior  management  brainstonning  session.  Lastly,  senior  man¬ 
agement  will  provide  feedback  and  review  on  the  report. 

Middle  management  should  support  the  process  and  ensure  that  peo¬ 
ple  who  are  participating  are  able  to  be  at  their  assigned  activities  on 
time  and  without  interruptions.  Middle  managers  should  also  pro¬ 
vide  their  inputs  on  recommendations  during  their  brainstorming 
session. 

The  assessment  team  will  be  consolidating  information  on  recom¬ 
mendations,  generating  details  on  the  findings  and  consequences, 
and  facilitating  the  brainstorming  sessions.  They  will  consolidate, 
distribute,  and  brief  the  report. 

The  practitioners  should  provide  their  inputs  on  recommendations. 

The  baseline  findings  and  recommendations  report  has  been  deliv¬ 
ered  and  briefed  to  senior  management,  and  a  commitment  has  been 
received  to  proceed  to  the  next  phase. 
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Tasks 


The  subtasks  for  D.3,  Develop  Baseline  Findings  and  Recommenda¬ 
tions  Report,  are 

•  Generate  first  draft  of  findings  fragments. 

•  Conduct  recommendations  brainstorming  or  focus  group  ses¬ 
sions  with  practitioners,  middle  management,  and  senior  man¬ 
agement. 

•  Cluster,  categorize,  and  merge  recommendations. 

•  Generate  first  draft  of  recommendations  fragments. 

•  Distribute,  review,  and  update  first  draft  with  the  MSG  and  other 
selected  stakeholders. 

Develop  briefing. 

Distribute,  review,  and  update  final  draft  report  and  briefing. 

•  Deliver  report  and  brief  recommendations. 
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Glossary 


baseline  action  plan 


Baseline  findings  and 

recommendationsrepo 

rt 

capability  maturity 
model  (CMM) 


discovery  team 


executive  council 


functional  area 
representative 


installation  plan 


line  management 


management  steering 
group  (MSG) 


Plan  that  specifies  the  charter,  scope,  and  deliverables  for  a 
specific  baseline  effort. 

Report  describing  the  current  state  in  a  specific  area,  with 
prioritized  recommendations. 


A  description  of  the  stages  through  which  software 
organizations  evolve  as  they  define,  implement,  measure, 
control,  and  improve  their  software  processes. 

Team  that  explores  issues  and  develops  an  SPI  proposal  to 
senior  management. 

Group  in  large  organizations  that  defines  strategy  and  direction 
for  the  organization’s  process  improvement  efforts. 

Representative  of  a  specific  software  functional  area  (e.g. 
configuration  management,  testing,  coding,  etc.)  who 
contributes  to  a  discussion  group  during  a  software  process 
assessment  (SPA). 

Plan  that  defines  steps  for  installing  an  improvement  in  a 
subunit  of  an  organization. 

The  first  and  second  level  of  management  in  a  medium  to  large 
organization  whose  focus  is  on  the  day-to-day  activity  of  the 
organization. 

Group  responsible  for  linking  the  SPI  program  to  the 
organization’s  vision  and  mission,  demonstrating  sponsorship, 
allocating  resources,  monitoring  progress,  and  providing 
guidance  and  correction. 
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management  steering 
group  (MSG)  charter 

middle  management 

organization 
communication  plan 

organization  strategic 
plan  for  software 
process  improvement 
(SPI) 

organization  vision 

pilot 

pilot  plan 

practitioner 

process 

process  action  team 
process  architecture 

process  database 


Document  that  defines  the  mission  of  an  MSG. 


Those  levels  of  management  between  senior  management  and 
line  management  in  a  medium  to  large  organization  whose 
focus  is  on  short-  to  mid-range  business  activities. 

Plan  for  creating  organization-wide  awareness  and 
involvement  with  the  SPI  program. 

Framework  for  SPI  in  the  context  of  the  organization’s 
business. 


A  mental  image  of  what  an  organization  will  be  when  its  goals 
have  been  accomplished. 

Initial  implementation  of  an  improvement,  usually  on  a  small, 
controlled  scale,  before  general  installation. 

Plan  that  defines  the  steps  for  conducting  a  pilot  in  an 
organization. 

A  person  who  is  working  within  the  software  development 
framework. 

The  means  by  which  people,  procedures,  methods,  equipment, 
and  tools  are  integrated  to  produce  a  desired  result. 

See  technical  working  group  (TWG). 

Framework  within  which  the  software  development  activities 
are  performed. 

A  repository  of  artifacts  containing  records  of  the  data  gathered 
and  generated  during  the  SPI  process. 
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rollout  strategy  and 
plan 

senior  management 


software  engineering 
process  group  (SEPG) 


software  engineering 
process  group  (SEPG) 
charter 

software  process 
improvement  (SPI) 
strategic  action  plan 


software  process 
improvement  advisory 
committee  (SPIAC) 

software  process 
improvement  (SPI) 
briefing 

software  process 
improvement  (SPI) 
implementation  plan 

software  process 
improvement  network 
(SPIN) 


Definition  of  the  strategy  and  plan  for  extending  improvement 
to  the  organization. 

The  top  manager  and  his/her  direct  reports  in  a  medium  to  large 
organization.  Senior  management  focus  is  typically  on  the 
longer  range  business  activities. 

Group  chartered  by  management  to  build  and  reinforce 
sponsorship  of  SPI,  nurture  and  sustain  improvement  activities, 
and  ensure  coordination  of  the  SPI  effort  throughout  the 
organization. 

Document  that  defines  the  mission  of  an  SEPG. 


Plan — based  on  the  results  of  the  baselining  efforts,  the 
organization  improvement  goals,  and  the  resources 
available — which  provides  guidance  for  the  overall  SPI 
program  and  addresses  how  the  long-range  organization  goals 
will  be  reached. 

Forum  in  large  or  geographically  disbursed  organizations  in 
which  multiple  SEPGs  share  experiences,  lessons  learned,  and 
improvements  accomplished. 

Briefing  held  to  build  awareness  of  and  support  for  SPI. 


Plan  that  provides  information  necessary  to  launch  a  SPI 
program 


A  group  of  individuals  banding  together  to  explore  their 
common  interests  related  to  software  process  improvement. 
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software  process  Proposal  that  provides  information  to  management  that  is 

improvement  (SPI)  necessary  to  launch  a  SPI  program. 

proposal 

stakeholder  Person  who  has  a  specific  interest  and  would  be  affected  by 

decisions  and/or  changes  in  his  or  her  areas  of  interest. 

strategic  business  plan  Plan  that  specifies  the  business  mission,  business  goals,  and 

strategy  the  organization  will  pursue  for  achieving  them. 

tactical  action  plan  Plan  that  specifies  charter,  scope,  and  deliverables  for  specific 

improvement  efforts. 

target  group  A  group  on  which  attention  is  focused  with  the  intention  of 

influencing  them  to  change  the  way  they  approach  their  work. 

technical  working  Groups  created  to  address  a  particular  focus  of  the  SPI 

group  (TWG)  program. 

technical  working  Document  that  defines  the  mission  of  a  TWG. 

group  (TWG)  charter 
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